Colors and GRASS, recap.

I dusted this one off, as it seems pertinient to the discussions here.

Dave Beverstock bever@erim.org
Environmental Research Institute of Michigan (ERIM)
P.O. Box 134001 Ann Arbor, MI 48113-4001 313-994-1200 x2239

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
Xdrivers

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
183 values).

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
any effect.

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)
to 216.

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
explanation.

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@laurel.ocs.mq.edu.au
Macquarie University phone: +61 2 805 8356
NSW 2109, Australia fax : +61 2 805 8428

On Fri, 8 Oct 1993, Dave Beverstock wrote:

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).

In X, you can specify colors to the server either using abstract names or
using various kinds of numerical specifications. When you use a name like
'turquoise' or 'medium sea green', the first place that Xlib looks for the
name is in implementation-dependent client databases. The rgb.txt file you
mentioned is the human-readable form of such a database. If the color name
is not defined there, then the X server's database is consulted.

Numerical specification of colors can be device-dependent or
device-independent. In the former you write something like

  device-name:value1/value2/value3/value4

where device-name is Tek9999 or whatever, and the valueN are whatever that
monitor happens to require in the way of color specs. More common, of
course, are device-independent color specs containing 3 values for red,
green and blue components. These components can be hexadecimal or floating
point. Hex specs can each be 1-4 digits, i.e. 4-16 bits, wide per
component and are sent verbatim to the X server. Floating point values are
in [0.0,1.0] and are corrected by Xlib before being sent to the server.

Examples:

  rgb:ffff/0/0 # really bright red
  rgbi:1.0/1.0/1.0 # whitest of white

You should be able to try these out at shell level anyplace a color can be
defined:

  xclock -bg rgb:ffff/ffff/0 &

Your interpretation of the situation wrt rgb.txt is therefore incorrect. I
don't know of any reason why you can't specify colors to the server with
as many bits as you like, up to the maximum X11R5 limit of 48 bits. Using
RGB values, one is allowed to assume that the X server will match the
specified color as well as the device will allow. So this gets back to the
question of why a 24-bit monitor wouldn't display 24-bit colors with
GRASS. *That* question you answered quite succinctly, for which I am
thankful. I just wanted to straighten out the X-related stuff.

Does anybody know what the reasoning was behind this particular design in
GRASS? It would seem to me that if you can have forty-eleven categories in
a raster map, you should be able to have forty-eleven colors also.

I find this whole situation to be a nightmare.

As do I, friend, as do I.

-- Mark

Mark P. Line, Open Pathways Phone: +1-206-733-6040
P.O. Box F Fax: +1-206-733-6040
Bellingham, WA 98227-0296 Email: markline@henson.cc.wwu.edu