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

[Gerald Buckmaster]

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'll eventually get the hint!  You might consider an additional warning at that
prompt as well, for folks with my mentality.

Thanks Again!

Gerald

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
**************************************************************************



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