Re: [9fans] colormap

["Russ Cox" <rsc@plan9.bell-labs.com>]

I don't think the rgb2cmap problem that Rob mentioned
is related to your color map problems.  

> We made a Plan 9 pic formatted file, begin with m8, and k8 :-).
> The latter works fine on a truecolor display, but only 16 grey shades on
> 8bit display(pseudocolor).   This doen't change when we changed the
> colormap to say /lib/cmap/c7291.56.
> 
> The former (m8), instead, works fine on the 8bit dosplay with colormap of
> that c7291.56, but shows colors ^_^ on a true color display.  Where we 
> should check?

This admittedly bizarre behavior is exactly what I'd expect.

The hardware color map is not intended to be changed from the
default rgbv map.

In particular:
	- the draw operator converts between m8 and other formats
	  using rgbv, regardless of the hardware color map contents.
	- the draw operator assumes that an m8 image can be written
	  as is to an m8 frame buffer.

Your k8 image works fine on a true-color display because
you've got 256 greys available to you.  It doesn't look as
good on the 8-bit display because it gets projected onto
the color map, so you only get 16 greys.

Your m8 image shows colors on the true-color display because
you've lied about the channel format, saying it's color.
On your 8-bit display, you've broken an implicit promise to
the kernel that the hardware color map will be rgbv.
The lie and the broken promise happen to cancel each other
out, so that you see a full 256 greyscale image.  The kernel
thinks your image is some weird color image (in fact, the
one you see on the true-color displays), but it dutifully
copies the bits to the frame buffer, and the result is the
greyscale you wanted.

The short answer is that you can't get 256 greys on an
8-bit display without resorting to the hack you've discovered,
which has the disadvantage of not working on true-color displays.

Russ