[GRASSLIST:1640] floating color table questions

GRASS GRASS user
1

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

Can someone point me to a FAQ?

Gerald

--
**************************************************************************
Gerald Edward Buckmaster Jr., Editor, Webmaster, Imagery Analyst
Imagery Analysis Support Site - http://www.imagery-analyst.com
Imagery Analysis Support Newsletter - mailto:subscribe@buckoptimized.com
**************************************************************************

2

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@jps.net>

3

Regarding colour maps. When I run Grass and netscape concurrently,
netscape uses all my colourmap. Obviously I can run a text-only version
of
Lynx, but I'd much rather have a clour and image version of netscape. Any
ideas?

regards,
Gail.

Gail Higginbottom,
Centre for European Studies and General Linguistics,
University of Adelaide,
Adelaide, South Australia,
Australia. 5005.
and
Department of Physics and Mathematical Physics

ghigginb@physics.adelaide.edu.au

http://www.physics.adelaide.edu.au/~ghigginb/

(08) 8303:6440

4

On Tue, Mar 20, 2001 at 03:34:06PM +0930, Gail Higginbottom wrote:

Regarding colour maps. When I run Grass and netscape concurrently,
netscape uses all my colourmap. Obviously I can run a text-only
version of Lynx, but I'd much rather have a clour and image version of
netscape. Any ideas?

Netscrape is known to be bad like this. I think it does better if you
use 16- or 32-bit colormode for your X driver. 'Course you can't get
24-bit color at less than a 24-bit colormode. However, 16-bit really
isn't too bad (gets a little grainy, but not nearly as noticeable as
8-bit colormode, yuck).

--
Eric G. Miller <egm2@jps.net>

5

Gail Higginbottom wrote:

Regarding colour maps. When I run Grass and netscape concurrently,
netscape uses all my colourmap. Obviously I can run a text-only version
of Lynx, but I'd much rather have a clour and image version of netscape. Any
ideas?

Using "netscape -install" should cause netscape to install its own
private colourmap.

--
Glynn Clements <glynn@sensei.co.uk>

6

gail,

I have had to do this since 95?? when running Netscape under X at least if I want to use an other app and see something.
[it might be -ncol or -ncols, I am at a Win machine today & unix challenged :frowning: ]
netscape -ncol N where N is 64 or 128, the number of colours you want to give Netscape. Otherwise Netscape grabs them all and does not share them.

On the systems I administer nescape is a shell script in the path, /bin, before the real netscape.
#! /bin/sh
/usr/local/bin/netscape -ncol 64

You could get fancy with an if $1 & decide at startup how many colors.

At 03:34 PM 3/20/01 +0930, Gail Higginbottom wrote:

Regarding colour maps. When I run Grass and netscape concurrently,
netscape uses all my colourmap. Obviously I can run a text-only version
of
Lynx, but I'd much rather have a clour and image version of netscape. Any
ideas?

regards,
Gail.

Gail Higginbottom,
Centre for European Studies and General Linguistics,
University of Adelaide,
Adelaide, South Australia,
Australia. 5005.
and
Department of Physics and Mathematical Physics

ghigginb@physics.adelaide.edu.au

http://www.physics.adelaide.edu.au/~ghigginb/

(08) 8303:6440

nigel dyson-hudson, InternetSmiths, Inc.
"Internet since lynx and mosaic days"
"I was Internet when Internet wasn't cool"

7

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@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@buckoptimized.com
**************************************************************************

8

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@jps.net>