grass-lists-owner at max.cecer.army.mil
grass-lists-owner at max.cecer.army.mil
Thu Aug 12 22:20:32 EDT 1993
***** UNDELIVERABLE MAIL sent to bonifaz, being returned by igiris!bonifaz *****
mail: Error # 8 'Invalid recipient' encountered on system igiris
Received: from max.cecer.army.mil by igiris via SMTP (911016.SGI/890607.SGI)
(for bonifaz) id AA00296; Thu, 12 Aug 93 19:19:56 -0700
Received: from amber.cecer.army.mil by max.cecer.army.mil with SMTP id AA23528
(5.67a/IDA-1.5 for <bonifaz%igiris at igiris.igeograf.unam.mx>); Thu, 12 Aug 1993 19:10:11 -0500
Received: from zorro.cecer.army.mil by amber.cecer.army.mil (4.1/SMI-4.1)
id AA01006; Thu, 12 Aug 93 19:04:31 CDT
Received: from amber.cecer.army.mil by zorro.cecer.army.mil with SMTP id AA13407
(5.67a/IDA-1.4.4 for <grassu-people at amber>); Thu, 12 Aug 1993 19:04:29 -0500
Received: from max.cecer.army.mil by amber.cecer.army.mil (4.1/SMI-4.1)
id AA01000; Thu, 12 Aug 93 19:04:26 CDT
Received: from laurel.ocs.mq.edu.au by max.cecer.army.mil with SMTP id AA23303
(5.67a/IDA-1.5 for <grassu-list at max.cecer.army.mil>); Thu, 12 Aug 1993 19:01:56 -0500
Received: by laurel.ocs.mq.edu.au id AA27487
(5.65c/IDA-1.4.4 for grassu-list at max.cecer.army.mil); Fri, 13 Aug 1993 10:00:50 +1000
Date: Fri, 13 Aug 1993 10:00:50 +1000
From: Peter Briggs <pbriggs at laurel.ocs.mq.edu.au>
Message-Id: <199308130000.AA27487 at laurel.ocs.mq.edu.au>
Sender: grass-lists-owner at max.cecer.army.mil
Reply-To: grassu-list at max.cecer.army.mil
Sender: grass-lists-owner at moon.cecer.army.mil.
Reply-To: grassu-list at moon.cecer.army.mil.
To: grassu-list at max.cecer.army.mil
Subject: Re: How many colors in Xdriver displays?
My apologies to the list for sending this originally without a
Simon and Phil write...
>We would like to understand why so few colors are displayed
>for raster maps. We are using Grass4.1 on Sparcstations using
>Solaris 1.1 (ie BSD Unix) under Openwindows3.0 etc etc and
>Even when the colr table has been customized in various ways
>(ramps, explicit RGB values, etc) so that it has a large
>number of required colors (& categories!) it seems that
>the Xdriver only finds a small number of colors to use.
>(eg only a dozen colors when I am asking for 1000's defined
>as ramps in one case, and similar for a custom color table with
>8-bit color means 256 different displayed values, right?
>We don't get anywhere near that! (though choosing "random colors"
>does appear to show more) colormode float does not seem to have
Simon and Phil,
You are addressing a problem that has caused me an enormous amount of
frustration along the way... Here is what I 'know' and/or reckon I have
figured out. My apologies for inaccuracies--I welcome corrections.
The first component of the problem has to do with GRASS, and variants
of your question have appeared on the list before and been answered
by Michael Shapiro. It is not documented in the r.colors reference
page, but GRASS reserves a number of places in the colour lookup
table for vectors (I think it's 16 or so), which leaves a theoretical
limit for the number of colours you can assign to a raster map as 240
or so. For reasons that I forget the practical limit in the past has
been found to be more like 220 colours (This may have been fixed).
If you try to assign more than 220 or so colours GRASS will
default to a 6x6x6 colour cube, inexplicably (to the user) cutting
down the number of accessable colours from 16.7 million (256^3)
Now I begin talking off the top of my head:
Accepting that you limit the number of colours you assign to 220
or so, the second component of the problem has to do with the
X-windows environment. Although you can theoretically access any
of 16.7 million different rgb combinations to create your 220 colours,
Normally in the /usr/lib/X11 directory is a plain text file (rgb.txt)
that has a list of r,g, and b values, and colour names, which
describe the colours that you can _actually_ access (I guess).
On my machine
the list is only 738 colours long, and many of those are different
names for the same rgb combination. The practical implication is
this: Let's say you want to plot your elevations from 0m to 220m
as intensities of green from 35 to 255, and you call for a ramp in the
rules file to do this. In my rgb.txt file there are
only 5 'distinct' greens out of the list of 7 'between' 0 0 0 and
0 255 0:
R G B NAME
0 255 0 green
0 255 0 green1
0 238 0 green2
0 205 0 green3
0 139 0 green4
0 100 0 dark
0 100 0 darkgreen
As far as I can tell, the colour displayed for each of your 221 rGb
values will be the closest to it of these five. If you use r.colors
color=rules with green intensities of your own choosing (ignorant
of the only five possibilities) you can easily find your different
categories being assigned to the same colour with no obvious
It seems as though one never REALLY knows exactly what colours are
being displayed unless you are ever-mindful of the rgb.txt file and
pick your colours based on those rgb values. I've found it useful
to write a little program that looks at the rgb.txt file and tells
me the number of actual colours 'between' two rgb values before I
decide to ask for a ramp between them. My next question is,
will hardcopy colour output show a continuously graded range of greens
or 5 distinct ones? I'd also like to know if I can create my own
rgb.txt file with 16.7 million entries and be done with it.
For what it's worth there is a utility called Xcolors which will allow
you to view the colours in the rgb.txt file by name (but not show you
their rgb values).
I find this whole situation to be a nightmare.
Cheers, Peter Briggs
School of Earth Sciences email: pbriggs at laurel.ocs.mq.edu.au
Macquarie University phone: +61 2 805 8356
NSW 2109, Australia fax : +61 2 805 8428
More information about the grass-user