A little while ago, I wrote about the use of color-keyed overlays to render video smoothly. The idea is that the CPU itself produces an image with a block of solid color (green in my example), and the graphics card is instructed to replace those pixels with the pixels from an off-screen image that it generated separately. Rather than doing the image composition in the CPU, the composition happens in the video card as the image leaves the card and goes to the monitor.
In the subsequent discussion, some people remembered this technique but noted that in their recollection, the color-key was not green but some other color. What’s going on?
When you set up the color-keying with the video card, you gave it a few instructions. You told it where to find the off-screen replacement image and how big it was. You told it the size and location of the on-screen rectangle where the replacement image should go. And you told it the magic color to look for inside that rectangle.
So the CPU got to pick the color-key color.
Choosing a color-key color was a bit tricky. If another window overlapped your video playback window, and they used your color-key color, then your video would play “through” the other window at any place it used that color. Therefore, when choosing a color-key color, you wanted to pick a color that is not commonly encountered. You didn’t want white or black, for example, because those are all over the place. Common choices were either neon-bright colors such as bright green or bright magenta because they are so ugly that nobody would even use them on purpose, or very dark colors like #010000 because they are so close to black that most normal people would just pick black outright.
The neon-bright colors were also useful when debugging because it’s extremely noticeable when you messed up.
Video card support for overlays was extremely varied. Some cards didn’t support them. Others did, but with restrictions. For example, “Oh, I can do overlays, but no more than four at a time, and they cannot have overlapping destination rectangles, and furthermore, I cannot apply a scale factor smaller than 1.0 or larger than 1.3.” Navagating all of these limitations and restrictions was quite a cumbersome undertaking for programs that wanted to use the feature.
The key to all this overlay trickery is that the magic happened inside the video card, and the result went out to the monitor without ever being sent back to the CPU. Programs themselves never saw the result of the overlay. All that programs saw or knew about were the color-keyed pixels. When you took the screen shot, you got the green (or whatever) pixels. When you loaded the bitmap into Paint, it showed green pixels, (but if an overlay was active, the video card changed them to something else before sending them to the monitor). When Paint saved the bitmap, it just saved green pixels. As far as anybody on the computer could tell, those pixels were just boring green pixels.
Did the color-keying ever use the alpha channel, or just RGB?
There wasn't really an alpha channel in this era of hardware - it was all RGB or luma/chroma format like YCbCr, NTSC YIQ, SECAM YDbDr, and PAL YUV. Framebuffer layouts might well have unused bits (32 bpp especially), but the hardware design was usually optimized to work well if you used 8 bpp or 16 bpp modes, which have no unused bits (either a palette for 8 bpp modes, or 5:6:5 R:G:B for 16 bpp modes).
Both of the common designs I encountered only had a 24 bit register for the "key" value; one design aligned the pixel from the framebuffer...
Fond memories of discovering this as a teen with our ATI capture card.
ATI Video Player used a magenta overlay, so if we put Paint in front of the player and drew in magenta, we could draw TV on the picture!
There was a good reason to use green over magenta or near-black in development, too. If you use separate chroma/luma in some form (e.g. YCbCr), then an all-bits-set buffer is likely magenta, and an all-bits-clear buffer is likely a blue colour.
Thus, when working with common video codecs, and using a bright green overlay colour, you got quick visual debugging for simple mistakes: if the image is green, you've not turned on overlays and you're seeing the colour-key. If it's magenta, the codec is setting all the bytes in the video supplied to the overlay to 255. If it's blue, it's...
I recall DirectX using the bright neon green and magenta in debug mode to signify to the developer uncleaned (e.g. uninitialized) video memory.
Was quite funny, when the debug runtime was installed, and a few professional games showed those colors in between.
> very dark colors like #010000 because they are so close to black that most normal people would just pick black outright
/me looks at new Windows Console & Terminal, where “black” is now defined as RGB(12, 12, 12)…