Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!husc6!linus!alliant!cantrell
From: cantrell@Alliant.COM (Paul Cantrell)
Newsgroups: comp.sys.mac
Subject: Re: 24-bit Video
Message-ID: <1273@alliant.Alliant.COM>
Date: 24 Feb 88 15:50:51 GMT
References: <3634@batcomputer.tn.cornell.edu> <1118@cpocd2.UUCP>
Reply-To: cantrell@alliant.UUCP (Paul Cantrell)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 118

In article <1118@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>No no no!  The main reason to have lookup tables is so you can have more
>potential colors displayable than there are color codes available.  This makes
>perfect sense with up to about 12 bit-planes.
>
>But with 24 bits, YOU DON'T NEED A LOOK-UP TABLE!  You can actually just say
>how much RGB you want, independently, for each pixel.  This is the ideal
>solution for many image-processing applications, and saves endless horrible
>kludges (like special programs to calculate what the best 256 colors are to
>represent a given picture).
>
>Now, there are SOME applications where you still want lookup.  An IC layout
>system like Magic is one example: it is easier for the software to allocate
>one bitplane per mask layer, and be able to do screen manipulations with
>one bitplane active and the others write-protected.  But even in these
>applications, you're losing a lot of power because of the separate LUTs.
>Three 8-bit LUT's give you at most 768 available colors, but direct 24 bit
>(no LUT) gives you 16M colors simultaneously displayable (if your display has
>that many pixels!).

I have to disagree with you about this. There are many uses for lookup
tables besides allowing selection of a subset of colors out of a larger
color space. Your example of Magic was a good one. Another example would
be imaging applications which want to do color correction without having
to change megabytes of image memory.

I think you may misunderstand how a 3x8-bit lookup table can work (or
you have used one that is braindamaged). Each entry in the 8-bit lookup
table has 24 bits of RGB information. So you have the full 16M colors
available to each of the three lookup tables. Since each 8-bit lookup
table produces a full RGB value, the hardware must combine the three
RGB values. One method would be to just sum them. So the final value
of the RED gun would be R1 + R2 + R3 where R1 is produced by the #1
lookup table, R2 by the #2 table, etc.

You will notice that you have simultaneous access to all 16M colors, if
you so desire. To do this, you can just set lookup table #1 to produce
256 different red values, table #2 to produce 256 different green values,
table #3 to produce 256 different blue values. So at a cost of 2304
bytes of lookup table (3 tables * 256 entries * 3 bytes per entry)
you can make it work just like a direct mapped frame buffer.

Is this useful? You bet. Lets assume you want to change the contrast
of the image. How do you have to do this with a direct mapped frame
buffer? Rewrite 24 megabytes of image memory. Pretty time consuming.
How do you do it with the 3x8-bit lookup table? Rewrite 2304 bytes of
lookup table. Effectively instantaneous.

What if you have an image with only 6 bits of red, green, and blue (for
a total of 18 bits of depth). With a direct mapped frame buffer, you
still have to use the full 24 bits to produce the image, so the extra
6 bits are wasted. Using the 3x8bit lookup tables you could use the
extra 6 planes for overlay graphics, mouse cursors, etc.

The only problem with color maps that I really detest is that there is
usually only one color map, when there may be several applications
sharing the screen. Applications typically do a really poor job of sharing
color maps. They frequently stomp on each other.

Therefore, if I had to come up with a proposal for a color map system
for the mac with access to 16 million colors, it would look something
like this:

	32 bits deep, arranged as follows:

	5-bits ->color map selector
	3-bits ->overlay graphics

	8-bits ->lookup table #1
	8-bits ->lookup table #2
	8-bits ->lookup table #3

The color map selector selects which of 32 different color maps is used.
Each application (or window) gets assigned a unique color map. For each
of these 32 different color maps, you get a full 3x8-bit lookup table.
This way each application can have complete control over how its
image gets mapped into colors. You can run Magic and an true-color imaging
application simultaneously (incase you happen to be a VLSI designer with
interest in the graphics arts).

The overlay graphics is for use by the system software for mouse cursors,
etc. Of the 8 colors, I can think of:
	0 = transparent (application image shows through)
	1 = black
	2 = white
	3 through 7 various primary colors (red, blue, green, yellow, etc).

Each lookup table entry would look like:

	+--------+----------+---------+-----+-------+------+
	| RED OP | GREEN OP | BLUE OP | RED | GREEN | BLUE |
	+--------+----------+---------+-----+-------+------+
bits:	    2         2          2       8      8       8

So you get 8 bits for each color, plus 2 bits of operation which is
used to determine how the hardware combines the color with the other
two color values (from the other two 8-bit lookup tables). I havn't
thought out exactly which operations you need, but here is an example.
Lets assume we are talking about the RED-OP field:

	OPERATION 0 -> Sum this value with the other two RED values
	OPERATION 1 -> Subtract this value from the other two RED values
	OPERATION 2 -> Logical OR this value with the other two RED values
	OPERATION 3 -> Use this value as an AND mask for the other two RED
			values.


Total cost in memory of this color map scheme would be:

	4 bytes per lookup table entry
	256 lookup table entries per 8-bit lookup table
	3 8-bit lookup tables per color map
	32 color maps

	98304 bytes of expensive high speed memory.

Additional cost is 1 byte per pixel of image memory, so on a 640x480
screen this would be 307200 additional bytes, or on a 1280x1024 screen
this would be 1310720 extra bytes. Yikes.