August 8, 1996

I wrote a program to show stereo pictures, which I describe below and can be found on this link:

ftp://ftp.psych.indiana.edu/pub/busey/AdjustStereoPicts.sea.hqx

To understand how this works, a little background on video cards would help. 8 bit video systems can show up to 16 million colors, but only 256 at a time. They do this by having each pixel contain a number from 0 to 255 than is an index into the lookup table that contains the actual rgb triplet for that color. 24 bit video cards have 24 bits per pixel, so they can store 8 bits for red, 8 bits for green and 8 bits for blue right in the video card (plus 8 bits for an alpha channel, which is why millions of colors video cards are 32 bits not 24 bits). Since the RGB triplet is stored right in the pixel, no lookup table is required and thus these devices are called 'direct devices'.

But, the cool thing is that these video cards do have lookup tables. The color value in the rgb triplet (0 to 255) actually is an index into these lookup tables, but there is a separate lookup table for red, green and blue. Normally the values in the lookup tables are the same as the index numbers:

Index # Value
0 0
1 1
2 2
.
.
.
255 255

However, we can change the values to anything we want. If we wanted to invert the reds on the screen, so what was saturated with red now becomes unsaturated with red and vice versa, we could just invert the red table:

Index # Value
0 255
1 254
2 253
...
255 0

The greens and blues would look fine; the reds would be inverted.

Now that we have complete control over the individual indices, we now take a stereo pair and compress the two images. What we are going to do is for the left image compress all the red, green and blue colors down to colors ranging from 0 to 15. Hackers will note that this is the lower 4 bits of the 8 bits allocated to each color channel. We then compress the colors from the right image to the values 16, 32, 64, ... 240, or in other words the higher 4 bits of the 8 bits per color channel. Initially these colors will look very strange, especially the left image which will look very dark. But remember, we have complete control over the eventual interpretation of the color values in each pixel through the direct cluts described above.

Ok, so we now have the left image with colors only in the lower 4 bits and the right image with colors only in the higher 4 bits. This color translation actually takes place offscreen in gworlds, so you don't see this (actually, there is a switch to have it take place onscreen because I like to watch it happen...). We now just add these two pictures together using copybits (or maybe copybitsquickly; I can't remember). We can't get overflow, because the largest value we will get is a 240 from the right picture and a 15 from the left picture, which gives 255.

This process takes about 2 seconds per image. One could speed it up a whole bunch by pre-translating and adding the images ahead of time. We now simply copy the image to the screen. However, we don't want the image to show up right away, so we set all of the entries in the three cluts to 0 (black) or 128 (grey) or 255 (white) depending on what you want your blank screen to look like. When it comes time to show the left image, we change the lower 4 bits of each clut entry to display the appropriate colors, leaving the upper 4 bits set to zero. The reverse is true for the right image. The actual values that are used in the clut are best derived by looking at the code itself.

The only other step is to synch the glasses to the clut switching, which is easy to do. Most clut calls wait for the vertical refresh to start, so swap in a new clut and switch the glasses state. Repeat as necessary as long as your stimuli are up.

To summarize, this technique relies on two things: the existence of a clut in each color channel of the 32 bit video card and the color compression techniques that move the colors in an image down to the lower 4 bits or upper 4 bits of the 8 bits per color allocated to each pixel. This technique was first published in a BRMIC article by Pete Dixon; others have used it as well. However, these only worked on 256 color systems.

Limitations: The techniques used in the AdjustStereoPicts program limit you to 16 colors per channel (4 bits), which slightly worse than thousands of colors mode on 16 bit monitors (these systems devote something like 5 or 6 bits per color channel; two have 5 bits and one has 6 bits). The other limitation is that I was still learning about color translation when I wrote the program, and it is sort of an ugly hack, so be kind when you read it. I'll be happy to answer questions about it.