CMap
Pictures today are stored in true color, which means each pixel is stored in 32 bits. These 32 bits contain the color directly:
- 8 bits for RED,
- 8 bits for GREEN and
- 8 bits for BLUE
Each color has 256 different shades which gives us 256 * 256 * 256 = 16777216 different colors.
You might say: "3 times 8 are only 24 bits, what happened to the remaining 8 bits in a 32-bit word?" and you are right. The remaining 8 bits are often, but not always, used for the alpha channel (256 steps of transparency).
Classic computers did not have enough video memory to use true color pictures, so they used different methods of encoding colors. It would be too much for this article to explain them all. Wikipedia might be a good source, if you are interested in more details.
In this article I would like to focus on the Color Table or CLUT and especially on how the CMM2 is using it.
As we already learned, true color images use 32 bits for each pixel to store the color. What would we do, if we only had 8 bits available for the color information? Store the color directly? Depending on the video hardware this could make sense. The Wikipedia article RGB Color Formats will tell you more about different color formats and where they were used.
The CMM2 has a different method to save video memory (only 8 bits per pixel) while keeping the full 32-bit color range: The CLUT - Color Look Up Table.
Instead of storing the color information directly, it stores the colors in a table of 256 entries, each 32 bits wide. Finally, we store the index of this table in the image instead. This way we can choose 256 different colors from a palette of 16777216 colors for our image and need only a quarter of the video memory for it. This is also called Indexed Video Mode.
This is the default CLUT of the Color Maximite 2:
Unfortunately, the CLUT built into the CMM2 video hardware is a write-only memory. That means, we can set a color register to a certain color, but we can't read it back. And this comes with some implications.
First, the default CLUT from the picture above is the default CLUT of the operating system. It is loaded to the video hardware at startup and after the basic command "map reset".
Secondly, MMBasic still allows you to set any color with the RGB(R,G,B) command. But because we have only 256 different colors available, the RGB() command checks for a color in the CLUT which is closest to the requested one and uses this instead.
From the CLUT?
No, the CLUT can't be read back. So, RGB() uses the default CLUT from the firmware. That is important to understand, if you use a custom color map and RGB() for color selection. To avoid any conflicts, we can use the command map() which takes a register number to set the color.
The source "cmap.inc" in this Gem compensates for the missing read capability by storing the color map before writing it to the video hardware. The CLUT still can't be read back, but we always know which color code has been set to which CLUT register. Unfortunately, this cannot compensate for the RGB() behavior which still uses the default firmware color table to find the "best" color.
This shows a custom color table. Please notice that not all of the 256 color registers have been modified.
The following picture shows an example of how the color table is addressed by an image. Each pixel represents a CLUT register shown as two-digit hexadecimal number. The small image above shows the real helicopter image.
To test the color map and play around with your own color tables, you can use the program ColorMap.bas where I got the above screenshots from.
To make custom color map handling easy, I implemented a reader for GIMP Palette files into cmap.inc.
It is a very simple text format, just containing one color per line, separated as R,G,B values in decimal. The "#" marks comments. See example below.
# GIMP Palette file
0 0 0 #0
255 0 0 #1
0 255 0 #2
0 0 255 #3
255 0 255 #4