Colors and GRASS, recap.

[Mark P. Line]

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 at henson.cc.wwu.edu