[GRASSLIST:1657] Re: floating color table questions

[Markus Neteler]

(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