Colortable mystery: black isn't black

Strange, but true!

I've been capturing raster images of the GRASS display window and sending
them through the pnm utilities for conversion to PostScript for some time now.
But just recently I stumbled on a problem.

I printed an raster map with no data set to RGB 0 0 0 (black), but it came out
dithered on the PS printer. I have since begun storing the original raster
dumps and exploring with the color editor of the xv utility. Interestingly
enough, black (as in d.erase black) was being stored as 42 42 42. I tried
setting d.colormode fixed, but to no avail.

I asked two other GRASS users to do the same, i.e. d.erase black, raster
capture, and probe with the color editor. One user did get RGB 0 0 0,
the other a 42 42 42 mix as I had. In neither case were there many unique
colors in the capture (nothing approaching 256).

Can anyone throw me a rope on this one?

greg

******************************************************************************
Greg Koerper Internet: greg@heart.cor.epa.gov
ManTech Environmental Technology, Inc. UUCP: hplabs!hp-pcd!orstcs!koerper
US EPA Environmental Research Lab
200 SW 35th St., JSB
Corvallis, OR 97333 "The 90s will make the 60s look like the 50s.
(503) 754-4490 Just ask your kids."
fax: (503) 754-4338
******************************************************************************

I had about the same problem when converting an Xwindowdump to pnm.
Instead of black not being real black, white appeared to be not really white.
I tried to figure out what xwdtopnm does, and it appeared that the program
thought the maximum (X) value of RGB should be 65535. In our case, the maximum
value was 65280!!!. When I changed the 65535 to 65280 at the appropriate places in the program, everything worked fine. I can imagine that this can also
cause your blacks not being real blacks. BTW, we also have a program, called
xpr, wich can make (B&W)postscript out of an X-windowdump.

Ronald Wiemer,

ARCHIS-centre of expertise,
Amersfoort, The Netherlands.