Color Bit Depth Reducer

The Color Bit Depth Reducer is a simple and convenient utility that down converts 24 bit RGB color values to their closest equivalent in a variety of lower bit depths.

24 bit RGB is so called because it consists of 8 bits in each of the red (R), green (G) and blue (B) color components. As 8 bits represent up to 256 different values, 24 bit RGB allows for 256 x 256 x 256 or 16,777,216 unique colors.

Web Hex is a common way of representing 24 bit RGB by representing the color components as hexadecimal values. This utility will allow you to enter RGB values either as individual decimal bytes for each of the individual color components, or as a single string of Web Hex such as #E4A392.

After entering the color that you would like to convert to a lower bit depth, select the particular bit depth you require from the drop down list. You will notice there are two convert buttons. Simply click on the one next to the Web Hex entry if you entered a value there, or the other button if you entered decimal bytes for the RGB components.

The result of the conversion will be presented in the gray box below the Color Bit Depth Reducer. The RGB value returned is the 24 bit RGB equivalent of the lower bit depth version of the converted color. A Web Hex value is also returned for convenience. Finally a Native version of the color is presented. This is simply the color as it would be defined (in decimal) using the bit depth you down converted to. The number range in parentheses indicates the range of decimal values that particular bit depth supports for the color components. For example (0-7) simply means that each of the red, green and blue components support values from zero to seven.

Below is a pair of colors that begin in 24 bit RGB which are then down-converted (from left to right) to 18 bit, 12 bit, 9 bit and 6 bit color. As you can see, by reducing the color component bit depth it can become increasingly difficult to match the original color. This does not hold true for all colors however. In particular there will be no issues with down-converting colors which the lower bit depths are already able to display within their existing color gamuts.

As an example of use, let’s convert a nice orange color into the closest match that an Atari ST can display with it’s palette of 512 colors. The Web Hex of this color is #f57900 and so we enter this value into the corresponding Web Hex field below. From the drop down list we select 3|3|3 – 512 colors. This specifies that we want 3 bits in each of the red, green and blue color components which provides us with 512 unique colors. This is what the original specification Atari ST is capable of, though later models of Atari computers (STE/TT/Falcon) do support more colors.

After clicking the convert button we get the resulting Web Hex conversion value of #da6d00. In order to reproduce this on an Atari ST we would specify an RGB value of 3, 7, 4 while working on the ST.

Supported Color Component Bit Depths

Bit Depth Red Green Blue Colors Sample Use
21 bit 0-127 0-127 0-127 2,097,152 Nintendo 64
18 bit 0-63 0-63 0-63 262,144 VGA
16 bit 0-31 0-63 0-31 65,536 RGB 565
15 bit 0-31 0-31 0-31 32,768 High Color
12 bit 0-15 0-15 0-15 4096 Amiga
Atari STE
9 bit 0-7 0-7 0-7 512 Atari ST
Sega Genesis
6 bit 0-3 0-3 0-3 64 EGA
3 bit 0-1 0-1 0-1 8

How it works

As previously noted, 24 bit RGB color components have values that range from 0 – 255. In order to reduce values in this range to lower bit depth ranges, we need to know the maximum color component values supported by the various bit depths. Please refer to the table above for an overview of bit depths supported by this utility and their individual color component ranges. As an example, 12 bit color has red, green and blue color component values in the range of 0 – 15.

To begin we need to select a 24 bit RGB color to convert : RGB = 200, 143, 96. We can now calculate the equivalent in 12 bit color one component at a time. The Amiga uses 12 bit color and so we will be creating an Amiga compatible color. Let’s begin with the red value of 200. We will convert this into a 0-15 range value and just keep the integer part (discarding digits past the decimal point).

col = 200

amigaCol = col * 15 / 255

amigaCol = 11

By doing this again for the green and blue components we arrive at the equivalent Amiga RGB (12 bit) color : Amiga RGB = 11, 8, 5. The 15 in the formula above is the maximum value (0-15) that 12 bit color can support for each color component. The 255 is the maximum that 24 bit RGB color components can support. Simply change the 15 to match the maximum value of the color component bit depth you wish to convert to.

Finally, if we want to convert this back into 24 bit RGB in order to display it on modern hardware we simply flip things around (and again just keep the integer portion) :

col = 255 / 15 * amigaCol

Doing this for each of the color components results in our end result which is a 24 bit RGB equivalent of a 12 bit RGB Amiga color : 187, 136, 85.

Conclusion

Hopefully this utility will come in handy for those who want to get the correct color equivalents for classic computers such as the ST or Amiga, or for those who are still producing art directly on these platforms.

Comments

  1. Thanks a lot!
    I was looking for such tool for a long time.
    Now I can convert the bizarre Nintendo Entertainment System palette to the weird 18-bit RGB VGA!

    • …Except this tool doesn’t seem to include the NES?

      Or did you mean using it to convert a pre-existing 24-bit lookup table?

  2. Thanks a zillion times, I was just in need of this for mapping colors to an Amiga.

  3. First of all: You got a nice site here.
    Other than that: Don’t you have to calculate amigaCol = col * 16 / 256
    in order to cover the full color range beginning from 0?

    • You’d think so, but no. Otherwise the method of determining the colours would be very easy – just take the appropriate number of MSBs from the source colour and discard the rest. I believe this is how a lot of early emulators operated, for a start.

      However, you then end up suffering quite a lot of drift at the top or bottom end, depending on whether you fill the LSBs with 0s or 1s. Either white (and pale colours) will be a dull light grey, or blacks (and dark colours) will be a washed out dark grey, with colour desaturation to boot. The effect is quite subtle with minor conversions (e.g. 24 bit to VGA), but the more extreme ones (24 bit to/from ST, or EGA) can exhibit a surprising amount of colour tone distortion as a result.

      Therefore you really do have to properly count from 0, rather than from 1, as the scales involved are 0-3, 0-7, 0-15 … 0-255, not 1-4, 1-8 … 1-256, and the division doesn’t work properly if you try to do it that way.

      Think it through – with an even number of steps in the scale (as most palettes use channels with a power-of-two depth, unless it’s e.g. web safe 6-6-6, or NES/C64/Atari 8-bit custom palettes), and the bottom of the scale always being 0, you will therefore then always have an ODD number of steps above that. After which, you have to lock the highest of those to 255, meaning that, except for EGA, you’ll always have a non-power-of-2 number of steps in between… and for both EGA and all the others, they’re actually having to find their position within 254 possible locations.

      Thus it all gets very tricky to work out with a calculator, and your results actually tend to come out as decimal fractions rather than integers.

      For example, if memory serves, the four levels available in EGA are -not- 64, 128, 192, 256 as a poorly considered assumption would make it, (or 0, 64, 128, 192) but 0, 85, 170 and 255. Something of a difference, there. Even if you split the difference of the first ones and made the LSBs $10000 not $000000 or $111111, you’d end up with 32, 96, 160, 224. The two output palettes would look very different on-screen, and certainly one picture would print out looking quite nice whilst the other would be a washed out, low contrast mess.

      ST is something like 0, 36, 73, 109, 146, 182, 219, 255. And the STE & Amiga work on steps of 17… 0, 17, 34, 51 etc. Note that the 9 and 12 bit palettes therefore don’t actually have interstitial levels that coincide with each other between 0 and 255; you cannot “perfectly” display an ST image on an STE or Amiga. Also, until we get up to at least 15-bit depth, it’s hard to represent a properly decent “50%” grey. At 24 bit, the difference between 127 and 128 (and therefore the 127.5 ideal) is quite minimal, less than 1%, and when presented on their own would be impossible to tell the difference between. The difference between 31 and 32 (vs 31.5) on the VGA scale is still only about 3% and hard to be certain about. 15 and 16 (vs 15.5) for 15-bit is about the limit where the gap between the two is drifting far enough that you might be able to guess the difference without having any external reference, but they’re both only 3.3% away from the ideal. 12-bit extends this to 7 vs 8 (14% jumps), and 9 bit makes it a large 3 vs 4, so either level is 16.7% lighter or darker than the ideal…

      Thus you can’t just assume that “4” on the ST’s 1-8 scale (or “3” on the true 0-7) is actually “halfway”, because it ain’t. In fact, it’s more like “3/7ths”, the same as the levels in EGA are thirds of a 0-255 scale; 0, 1/3rd, 2/3rds, 1.

      • Incidentally this means the web-safe 216-colour cube works on FIFTHS of 255, as it has six levels for each of red, green and blue. Each one jumping by 51 in a 24-bit colour space, which is quite convenient; 0, 51, 102, 153, 204, 255. But makes it a right pain to back-convert to, say, the ST palette, or indeed a 15 or 16-bit colour system, even though it just so happens to work absolutely perfectly with the 12-bit one.

Speak Your Mind

*

Read previous post:
Build a 2×4 in POV-Ray

If you are just getting started with POV-Ray, this simple tutorial will show you how to raytrace a wooden 2...

Close