Indexed color

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (December 2012) (Learn how and when to remove this message) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Indexed color" – news · newspapers · books · scholar · JSTOR (December 2012) (Learn how and when to remove this message) (Learn how and when to remove this message)

In computing, indexed color is a technique to manage digital images' colors in a limited fashion, in order to save computer memory and file storage, while speeding up display refresh and file transfers. It is a form of vector quantization compression.

When an image is encoded in this way, color information is not directly carried by the image pixel data, but is stored in a separate piece of data called a color lookup table (CLUT) or palette: an array of color specifications. Every element in the array represents a color, indexed by its position within the array. Each image pixel does not contain the full specification of its color, but only its index into the palette. This technique is sometimes referred as pseudocolor^[1] or indirect color,^[2] as colors are addressed indirectly.

Early graphics display systems that used 8-bit indexed color with frame buffers and color lookup tables include Shoup's SuperPaint (1973) and the video frame buffer described in 1975 by Kajiya, Sutherland, and Cheadle.^[3][4] These supported a palette of 256 RGB colors. SuperPaint used a shift-register frame buffer, while the Kajiya et al. system used a random-access frame buffer.

A few earlier systems used 3-bit color, but typically treated the bits as independent red, green, and blue on/off bits rather than jointly as an index into a CLUT.

The palette itself stores a limited number of distinct colors; 4, 16 or 256 are the most common cases. These limits are often imposed by the target architecture's display adapter hardware, so it is not a coincidence that those numbers are exact powers of two (the binary code): 2² = 4, 2⁴ = 16 and 2⁸ = 256. While 256 values can be fit into a single 8-bit byte (and then a single indexed color pixel also occupies a single byte), pixel indices with 16 (4-bit, a nibble) or fewer colors can be packed together into a single byte (two nibbles per byte, if 16 colors are employed, or four 2-bit pixels per byte if using 4 colors). Sometimes, 1-bit (2-color) values can be used, and then up to eight pixels can be packed into a single byte; such images are considered binary images (sometimes referred as a bitmap or bilevel image) and not an indexed color image.

If simple video overlay is intended through a transparent color, one palette entry is specifically reserved for this purpose, and it is discounted as an available color. Some machines, such as the MSX series, had the transparent color reserved by hardware.^[5]

Indexed color images with palette sizes beyond 256 entries are rare. The practical limit is around 12-bit per pixel, 4,096 different indices. To use indexed 16 bpp or more does not provide the benefits of the indexed color images' nature, due to the color palette size in bytes being greater than the raw image data itself. Also, useful direct RGB Highcolor modes can be used from 15 bpp and up.

If an image has many subtle color shades, it is necessary to select a limited repertoire of colors to approximate the image using color quantization. Such a palette is frequently insufficient to represent the image accurately; difficult-to-reproduce features such as gradients will appear blocky or as strips (color banding). In those cases, it is usual to employ dithering, which mixes different-colored pixels in patterns, exploiting the tendency of human vision to blur nearby pixels together, giving a result visually closer to the original one.

Here is a typical indexed 256-color image and its own palette (shown as a rectangle of swatches):

How the colors are encoded within the color palette map of a given indexed color image depends on the target platform.

Many early personal and home computers had very limited hardware palettes that could produce a very small set of colors. In these cases, each pixel's value mapped directly onto one of these colors. Well-known examples include the Apple II, Commodore 64 and IBM PC CGA, all of which included hardware that could produce a fixed set of 16 colors. In these cases, an image can encode each pixel with 4-bits, directly selecting the color to use. In most cases, however, the display hardware supports additional modes where only a subset of those colors can be used in a single image, a useful technique to save memory. For instance, the CGA's 320×200 resolution mode could show only four of the 16 colors at one time. As the palettes were entirely proprietary, an image generated on one platform cannot be directly viewed properly on another.

Other machines of this era had the ability to generate a larger set of colors, but generally only allowed a subset of those to be used in any one image. Examples include the 256-color palette on Atari 8-bit machines or the 4,096 colors of the VT241 terminal in ReGIS graphics mode. In these cases it was common for the image to only allow a small subset of the total number of colors to be displayed at one time, up to 16 at once on the Atari and VT241. Generally, these systems worked identically to their less-colorful brethren, but a key difference was that there were too many colors in the palette to directly encode in the pixel data given the limited amount of video memory. Instead, they used a colour look-up table (CLUT) where each pixel's data pointed to an entry in the CLUT, and the CLUT was set up under program control. This meant that the image CLUT data had to be stored along with the raw image data in order to be able to re-produce the image correctly.

Hardware palettes based on component video colors such as YPbPr or the like were generally replaced in the mid 1980s by the more flexible RGB color model, in which a given color can be obtained by mixing different amounts of the three primary colors red, green, and blue. Although the total number of different colors depends on the number of levels per primary, and on a given hardware implementation (a 9-bit RGB provides 512 combinations, a 12-bit RGB provides 4,096, and so on), in this model digital-to-analog converters (DAC) can generate the colors — simplifying the hardware design — while the software can treat the number per levels used abstractly and manage the RGB colors in a device-independent fashion. With colors stored in RGB format within the palettes of indexed image files, any image can be displayed (through appropriate transformations) on any such system, regardless of the color depth used in the hardware implementation.

Today, display hardware and image file formats that deal with indexed color images almost exclusively manage colors in RGB format, the de facto standard encoding being the so-called truecolor or 24-bit RGB, with 16,777,216 different possible colors. However, indexed color images are not genuinely constrained to a 24-bit RGB color encoding; image palettes can hold any type of color encoding. For example, the PDF file format does support indexed color in other colorspaces, notably CMYK, and Adobe Distiller by default will convert images to indexed color whenever the total number of colors in an image is equal to or less than 256. When using RGB, the TIFF and PNG file formats can optionally store the RGB triplets with a precision of 16-bit (65,536 levels per component) yielding a total of 48 bits per pixel. A proposed extension to the TIFF Standard allows^[6] non-RGB color palettes, but this was never implemented in software due to technical reasons. The color map table of the BMP file format indexed color mode stores its entries in BGR order rather than RGB, and has (in the current version) an additional unused byte for padding to conform to 32-bit word alignment during processing, but it is essentially still a 24-bit RGB color encoding. (An earlier version of the BMP format used three bytes per 24-bit color map table entry, and many files in that format are still in circulation, so many modern programs that read BMP files support both variations.)

Except for very low resolution graphic modes, early home and personal computers rarely implemented an "all-pixels-addressable" design - that is, the ability to change a single pixel to any of the available colors independently. Their limitations came from employing separate color attribute or color RAM areas, leading to attribute clash effects. Also, the pixel bits and/or the scan lines of the video memory were commonly arranged in odd ways convenient for the video generator hardware (thus saving hardware costs in a cost-competitive market), but sometimes creating difficulty for the people writing graphics programs. A pixel's bits in indexed-color, all-pixel-addressable images are not always contiguous in video memory or image files (i.e., chunky organization is not always used.) Some video hardware, such as the 16-color graphic modes of the Enhanced Graphics Adapter (EGA) and Video Graphics Array (VGA) for IBM PC compatibles^[7] or the Amiga video buffer^[8] are arranged as a series of bit planes (in a configuration called planar), in which the related bits of a single pixel are split among several independent bitmaps. Thus, the pixel bits are conceptually aligned along the 3D Z-axis. (The "depth" concept here is not the same as that of pixel depth.)

Early image file formats, such as PIC, stored little more than a bare memory dump of the video buffer of a given machine.

Some indexed-color image file formats such as Graphics Interchange Format (GIF) allow the image's scan lines to be arranged in interleaved fashion (not linear order), which allows a low resolution version of the image to appear on screen while it is still downloading, so that the computer user can gain an idea of its contents during the seconds before the whole image arrives. Here is an example of a typical vertically interleaved download in four steps:

As seen here, the image has been divided into four groups of lines: group A contains every fourth line, group B contains lines immediately following ones in group A, group C likewise contains the lines immediately following those in group B, and group D contains the remaining lines, which are between group C lines (immediately above) and group A lines (immediately below). These are stored into the file in the order A, C, B, D, so that when the file is transmitted the second received group (C) of lines lie centered between the lines of the first group, yielding the most spatially uniform and recognizable image possible, composed of only two of the groups of lines. The same technique can be applied with more groups (e.g. eight), in which case at each step the next group to be sent contains lines lying at or near the centers of remaining bands that are not yet filled with image data. This method, with four or eight groups of lines, was commonly used on the early World Wide Web during the second half of the 1990s. Rather than leaving the background (black) showing as in the illustration above, the partial image was often presented on screen by duplicating each line to fill the space below it down to the next received image line. The end result was a continuous image with decreased vertical resolution that would increase to full resolution over a few seconds as the later parts of the image data arrived.

Indexed color saves a lot of memory, storage space, and transmission time: using truecolor, each pixel needs 24 bits, or 3 bytes. A typical 640×480 VGA resolution truecolor uncompressed image needs 640×480×3 = 921,600 bytes (900 KiB). Limiting the image colors to 256, every pixel needs only 8 bits, or 1 byte each, so the example image now needs only 640×480×1 = 307,200 bytes (300 KiB), plus 256×3 = 768 additional bytes to store the palette map in itself (assuming RGB), approximately one third of the original size. Smaller palettes (4-bit 16 colors, 2-bit 4 colors) can pack the pixels even more (to one sixth or one twelfth), obviously at cost of color accuracy.

Indexed color was widely used in early personal computers and display adapters' hardware to reduce costs (mainly by requiring fewer of the then-expensive RAM chips) but also for convenient image management with limited-power CPUs (of the order of 4 to 8 MHz), file storage (cassette tapes and low density floppy disks). Notable computer graphics systems extensively (or even exclusively) using pseudocolor palettes in the 1980s include CGA, EGA, and VGA (for IBM PC compatibles), the Atari ST, and Amiga's OCS and AGA.

Image files exchanged over the CompuServe net in the early 1990s were encapsulated in the GIF format. Later, the HTML web pages used the GIF along with other indexed color-supporting file formats such as PNG, to exchange limited-color images quickly and store them in limited storage space.

Most image file formats that support indexed color images also commonly support some compression scheme, enhancing their ability to store the images in smaller files.

Interesting colorized and artistic effects can be easily achieved by altering the color palette of indexed color images, for example to produce colorized sepia tone images. Due to the separate nature of the associated palette element of the indexed color images, they are ideal to remap grayscale images into false color ones through the use of false color palettes.

Simple video overlay can be achieved easily through the transparent color technique.

By manipulating the color hardware registers (Color look-up table or CLUT) of the display adapter in the indexed color graphic modes, full-screen color-animation effects can be achieved without redrawing the image - that is, at low CPU time cost; a single change of the register values affects the whole screen at once. Color-map animation, also known as Color cycling, is extensively used in the demoscene. The Microsoft Windows boot logo screen in Windows 95, 98, ME, and 2000 Professional (which uses VGA 320x200x256 color display mode because it is the greatest common denominator on all PCs) employs this technique for the scrolling gradient bar across the bottom of the screen; the picture is a static image with no pixels rewritten after it is initially displayed. Custom boot screen images could tap the cycled colors to animate other parts of the images.

The main disadvantage of using indexed color is the limited set of simultaneous colors per image. Small 4- or 16-color palettes are still acceptable for little images (icons) or very simple graphics, but to reproduce real life images they become nearly useless. Some techniques, such as color quantization, anti-aliasing and dithering combined together can create indexed 256-color images comparable to the original up to an acceptable level.

4-color	16-color	256-color	True color

Indexed color images are heavily dependent on their own color palettes. Except for a few well known fixed-color palettes (such as that of the Color Graphics Adapter—CGA), raw image data and/or color map tables cannot be reliably exchanged between different image files without some kind of intermediate mapping. Also, if the original color palette for a given indexed image is lost, it can be nearly impossible to restore it. Here is an example of what happens when an indexed color image (the previous parrot) has been associated with an incorrect color palette:

Indexed color graphic modes for display adapters have the 16- or 256-color limit imposed by hardware. Indexed color images with rich but incompatible palettes can only be accurately displayed one at a time, as in a slideshow. When it is necessary to show multiple images together, as in a mosaic of thumbnails, a common or master palette is often used, which encompasses as many different hues as possible into a single set, thereby limiting the overall accurate color availability.

The following image is a mosaic of four different indexed color images rendered with a single shared master palette of 6-8-5 levels RGB plus 16 additional grays. Note the limited range of colors used for every image, and how many palette entries are left unused.

Many indexed color display devices do not reach the 24-bit limit for the full RGB palette. The VGA for IBM PC compatibles, for example, only provides an 18-bit RGB palette with 262,144 different possible colors in both 16- and 256- indexed color graphic modes.

Some image editing software allows gamma correction to be applied to a palette for indexed color image files. In general, to apply a gamma correction directly to the color map is bad practice, due to the original RGB color values being lost. It is better to apply the gamma correction with the display hardware (most modern display adapters support this feature), or as an active intermediate step of the rendering software through color management, which preserves the original color values. Only when the indexed color images are intended for systems that lack any kind of color calibration, and they are not intended to be cross-platform, gamma correction may be applied to the color table itself.

These are some of the most representative image file formats that support indexed color modes. Some of these support other modes (e.g. truecolor), but only the indexed color modes are listed here.

NOTE: most of the formats will also support a color table with fewer colors than the maximum that a given bit depth can offer.

* 64- (true, not EHB), 128- and 256-color modes only available for the AGA Amiga chipset.

** Native support for proprietary compression schemes.

*** RLE with optional proprietary Delta-leaps.

• Color depth
• List of palettes
• List of home computers by video hardware

• Julio Sanchez and Maria P. Canton (2003). The PC Graphics Handbook. CRC Press. ISBN 0-8493-1678-2.

• Introduction to indexed color images