[GRASSLIST:1654] Re: floating color table questions

[Gerald Buckmaster]

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?  

Any Ideas?
Using Mandrake 6.1, Linux 2.2.13, GRASS 5.0b11
AMD K6-2, 192mb RAM, Never Enough HD...

Thanks!

Gerald

On Mon, 19 Mar 2001, Eric G. Miller replied to the following question:
> On Mon, Mar 19, 2001 at 09:55:37PM -0700, Gerald Buckmaster wrote:
> > Friends,
> > 
> > This is probably a very common question:
> > 
> > How do I view the full beauty of my multispectral imagery using GRASS?  With
> > ERDAS Imagine, I get some great looking imagery, but with GRASS, I apparently
> > cannot get past 8-bit?
> > 
> > Does this have something to do with the driver.  Something about a 24-bit
> > driver, I recall is how I fixed this before.
> > 
> > My attempt to set the colormode to floating is not working.
> > 
> > d.colormode mode=float
> > 
> > Sorry, floating color table not available on this device
> 
> "Float" colormode only works if there is a writeable colormap (it
> wouldn't help anyway).  TrueColor (24 bit) visuals are always (?) read
> only.  There's an "nlev" argument to d.mon in GRASS 5.0, allowing you to
> specify 24 bit color by using "d.mon start=x0 nlev=256" (256 == colors
> per channel r/g/b).  Unfortunately, the driver code isn't very
> sophisticated and using that many colors requires a large chunk of
> memory (for the colormap).  I looked at eliminating the color map for
> TrueColor visuals, but I couldn't quite decipher how to do it.  
> 
> 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.
> 
> I don't think these things will change for GRASS 5.0 at all (maybe 5.1).
> 
> NOTE: I think the CELL driver is only 8-bit color...
> 
> -- 
> Eric G. Miller <egm2 at jps.net>
-- 
**************************************************************************
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
**************************************************************************