[9fans] colormap

[9fans] colormap

[okamoto]

As we are much concerened with grey scale images rather than colored
ones.  I wanted to change colormap of _a_ window which is that for page2.
I cats the /lib/cmap/c7291.56 file to /dev/draw/<Num>/colormap, and
found that it changed colormap of whole of the /dev/screen.

Is it leagal to change the colormap of one particular window?

Kenji

Re: [9fans] colormap

[okamoto]

>Your m8 image shows colors on the true-color display because
>you've lied about the channel format, saying it's color.

Yes, we lied the Plan 9 kernel.  However, isn't it posssible to use another
colormap to change colormap to rgb by cmap2rgb(), which assumes only
rgbv colormap?

Without this lie, we have no chance to see 256 greyscale images on
8 bit display...   I found some codes in /sys/src/libdraw/rgb.c assuming 
only 16 shades of greyscale, which made us disappointed. 

Our local "lie and broken promise" method is as follows:  ^_^

To check what display depth we are in, and
(1) if we are on 8 bit display, make m8 'greyscale' data, and change colormap
to one having 256 grey shades, such as /lib/cmap/c7291.56.
(2) if we are on truecolor display, make k8 'greyscale' data.

We tried (r8g8b8) with same three bytes data, but it's just waste of memory.  :-)

Kenji

Re: [9fans] colormap

[Russ Cox]

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

Re: [9fans] colormap

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

We have been expanding this experiment, and found that we are following
previous rob's post on cmap2rgb() etc.   Ok!, I got the problem right, I think.
The general solution, however, may not be so easy... Then, we'll try to solve
the problem under some local assumptions.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2030 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] colormap
Date: Thu, 1 Mar 2001 10:52:49 0900
Message-ID: <20010301015323.2588B199EF@mail.cse.psu.edu>

We have many 8bit depth greyscaled images, and want to display them on
8bit and truecolor (>=16bit) display.

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?

Kenji

Re: [9fans] colormap

[okamoto]

We have many 8bit depth greyscaled images, and want to display them on
8bit and truecolor (>=16bit) display.

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?

Kenji

Re: [9fans] colormap

[Scott Schwartz]

> ...to have colormap entry just under the /dev/draw directory is better, I agree.

Unless you want to switch colormaps when window focus changes.

Re: [9fans] colormap

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 165 bytes --]

Yes, 8-bit display is going fade day by day except of notebooks, however,
to have colormap entry just under the /dev/draw directory is better, I agree.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 1869 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] colormap
Date: Wed, 28 Feb 2001 01:26:04 -0500
Message-ID: <200102280626.BAA24768@smtp4.fas.harvard.edu>

The color map is global, and corresponds
to what's programmed into the underlying hardware.
It's a small misnomer that the device file is
/dev/draw/nnn/colormap rather than /dev/draw/colormap.

Russ

Re: [9fans] colormap

[Russ Cox]

The color map is global, and corresponds
to what's programmed into the underlying hardware.
It's a small misnomer that the device file is
/dev/draw/nnn/colormap rather than /dev/draw/colormap.

Russ