[GRASSLIST:1655] Re: floating color table questions

[Eric G. Miller]

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 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...
> 
> 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.  
> 
> 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.
> 
> I am using named regions...can you explain a little more about how the region
> settings not matching the raster would effect the cell value decision process?
> 
> >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.

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!  

There's seems to be alot of color management stuff centered around 8-bit
color palettes.  It definitely needs to be expunged. 

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.  

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>