[GRASS5] Re: r.support & i.composite & number of colors

Markus Neteler neteler at geog.uni-hannover.de
Sat Mar 24 07:32:02 EST 2001


Hi Gerald,

On Fri, Mar 23, 2001 at 07:15:22PM -0700, Gerald Buckmaster wrote:
> Thanks to Markus and Eric for the answers provided below.
> 
> I probably should have read the part about 256 colors slowing down GRASS!
> Your answer, Markus: Yes, I assumed 256, not knowing the formula; and to top
> that off, I did it again after I successfully created histograms for the bands
> I needed with r.support!

I have added the formula to the i.composite html page.

> I'll eventually get the hint!  You might consider an additional warning at that
> prompt as well, for folks with my mentality.
Ok - the message is changed now from

 How many color levels?

to

 How many color levels (number of colors for each channel)?

Does this improved message help (any better ideas?)

> Thanks Again!
> 
> Gerald

Thanks for you hint!

 Markus



> On Wed, 21 Mar 2001, Markus Neteler asked an interesting question:
> > (cc to grass5) 
> > 
> > On Wed, Mar 21, 2001 at 12:18:03AM -0800, Eric G. Miller wrote:
> > > On Tue, Mar 20, 2001 at 11:30:57PM -0700, Gerald Buckmaster wrote:
> > > > Eric,
> > > > 
> > > > I tried d.mon's nlev option, with no change in depth, visually.  Let me explain
> > > > what is happening...this may just be ignorance on my part:
> > > > 
> > > > I use d.rgb to display separate files (bands), but they look like @#$%.
> > I agree... The i.composite produces better results (with color levels =10).
> > 
> > > > I use i.colors to basically accomplish the same task (without saving to a new
> > > > file) and the display looks great...just what I would expect from any
> > > > multispectral viewer,  however, I get a warning about the histogram not found
> > > > for each of the input files...
> > 
> > Run
> > r.support -r mapname
> > 
> > on each map. I have added a hint for this warning recently, in the next
> > version of GRASS 5 the user will be told to run r.support on the particular
> > file (change was done in src/libes/gis/histogram.c).
> > 
> > > > I use i.composite to write out to a file, knowing using a screengrabbing
> > > > utility is not really what I'm looking for...and I get the same histogram
> > > > warning and my prompt doesn't return.  
> > Same story: r.support.
> >  
> > > > I examine my processes and sure enough, i.composite is leading the pack in CPU
> > > > usage.  Great, this is really working...not.  14 hours later, no change...no
> > > > file.
> > How much color levels did you specify? Note: GRASS becomes *very* slow
> > with > 8000 colors. The formula for color *levels* is:
> > 
> >  number_of_colors = color_level^3
> > 
> > With color_levels=10 you receive 1000 colors. So, I would be interested,
> > if you specified 256 color levels :-)
> > 
> > 256^3=16777216 -> slooooow GRASS.
> > 
> > [...]
> > > > >One other thing that will degrade the quality of the visuals some is
> > > > > the way GRASS chooses cell values when the "region" settings don't
> > > > > match the raster. It should do some form of interpolation (nearest
> > > > > neighbor, etc...) but instead just chooses the closest cell for the
> > > > > given
> > > > >resolution.  This can make the image a bit "pixelated" looking.
> > > > 
> > > > This statement interests me...could i.colors be utilizing code that
> > > > could be reused by d.rgb and others?
> > > 
> > > I just looked at d.rgb last night.  For some reason, it hardwires the
> > > colors to 8-bit.  Hence, it looks like @#$%!  I tried hacking it to
> > > do a 24bit color palette, but I wasn't quite getting the match between
> > > cell values and the color palette right (actually, I was getting it
> > > quite wrong <*g*>).  Can't guarantee I'll get it "fixed-up" anytime
> > > soon.
> > 
> > Work has to be done here, the d.rgb and friends are already on the TODO/BUGS
> > list.
> > 
> > > As far as the histogram thing goes, "r.support" will give you an option
> > > to update histogram/stats.  I believe i.composite uses the histogram to
> > > match up colors better.  I've had the same experience with i.composite.
> > > I don't know what it's doing, but it takes forever to get there!  
> > Yes, without a proper map's histogram the i.composite produces ugly
> > pictures (therefore the warning).
> > 
> > > There's seems to be alot of color management stuff centered around 8-bit
> > > color palettes.  It definitely needs to be expunged. 
> > Yes.
> > 
> > > As far as the region settings go.  Say your region cellsize is twice as
> > > large as the resolution of a raster you wish to display.  As far as I'm
> > > aware, the library code just grabs the cell that matches on centers the
> > > best with each cell at the current region settings (make sense??).  So,
> > > it doesn't do something like a weighted interpolation of the values,
> > > which for continuous data (imagery, etc..) should lead to a smoother
> > > image.  
> > To avoid confusion: At least with calculations (if you use r.mapcalc and
> > a non-matching resolution) it is using a cell average. Above is only
> > the (current) limitation for displaying data. Probably the display
> > lib needs an update here to be compliant with general raster library.
> > 
> > > The region idea works well for matching up cell values for analytical
> > > functions, but I don't know that it's such a good idea for display.  I
> > > think display stuff should try to optimize resolution for the target
> > > (window, graphics file, etc...).
> > > 
> > > -- 
> > > Eric G. Miller <egm2 at jps.net>
> > > 
> > 
> > Regards
> > 
> >   Markus Neteler
> -- 
> **************************************************************************
> Gerald Edward Buckmaster Jr., Editor, Webmaster, Imagery Analyst
> Imagery Analysis Support Site - http://www.imagery-analyst.com
> Imagery Analysis Support Newsletter - mailto:subscribe at buckoptimized.com
> **************************************************************************
> 
> 

-- 
Markus Neteler *  University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494  Fax: -3984

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list