If I take a 24 bit image and reduce it to 8 bits with save as of any simple drawing, the result is terrible; as any modern computer user would know. It was the same in the late 90s when I had access to 16 bit depth; converting to 8 bit depth was terrible.

But I remember the days of the Multimedia PC and S3 cards and 8 bit depth. It wasn't terrible. You had to be a really good programmer to make it come out well because of palette control (and the background program always went to trash) but it worked. I used to painstakingly hand-construct 256 color images.

But we had these encyclopedia and other programs that had 256 color images and videos that were awesome at the time. Granted, they show so many artifacts now that the videos look bad to modern eyes. But neither the videos nor the images are the terrible of reducing 16 bit depth to 8 bit depth. This is not rose colored glasses-my multimedia PC era CDs are still readable and I called one up to verify. It's as I remember it. The images are reasonable; much better than someone dealing with 16 bit to 8 bit conversion would expect.

The images could not have been taken with an 8 bit camera. That's mathematically impossible. They have to have been taken at a higher bit depth and downleveled to 8 bit; what happened? Why are the converters immediately at our fingertips so bad and how could they be good?

  • 4
    What do you mean by ‘terrible’? Mar 1 at 6:48
  • 11
    @cup 256-colour displays used palettes, they weren’t fixed RRRGGGBB. Mar 1 at 9:18
  • 7
    Your question is based on a false premise based on your own experience. In the Windows 3.1 era, home photo editing (from scanning, not from digital cameras yet) was becoming HUGE - there were PC magazines aimed at home users, and even in the 90s they would fill cover CDs (or more likely floppies) with image software. My personal experience is the 16bit version of Paint Shop Pro 3 (and later 32bit PSP4). These programs could manipulate 16/24bit truecolor images internally while using a 256 colour display, and had good colour reduction algorithms for exporting higher depths as 256 colour images.
    – knol
    Mar 1 at 11:48
  • 2
    @Joshua yes, you could have — ImageMagick was released in 1990 and was quite capable early on. Like knol said, PSP was very good at this too, even in the early 90s. Mar 1 at 16:59
  • 3
    The main problem is that probably most programs today default to reducing to the 8-bit web-safe color pallet, which results in only 216 fixed colors. Most programs, take GraphicConverter for example have the option to 'Optimize' the color pallet, which results in the best 256 colors (chosen out of 16.7 million colors) to represent the original picture. If you have 2 such pictures that are highly different, there may be 512 colors used between them, and viewed on a 16-bit or better display they'll look fine, but viewed together on an 8-bit display, at least one will look bad.
    – Glen Yates
    Mar 1 at 22:06

6 Answers 6


There are two key points to generating good looking 256-color images: Choosing a proper palette and obscuring color errors (usually by some kind of dithering).

If you want to display only a single image at a time, you can create a palette adapted to that image. Properly choosing the palette color immensely reduces the amount of color errors you had to conceal.

In case you want to display multiple arbitrary images at a time, you can not optimize the palette to specific images, but you would need to settle on a common palette for all images.

There are two fast ways for down-converting high color images: Just choose the nearest palette color (creates awful banding) and dithering with a regular pattern derived from the low bit(s) of the X/Y coordinate values (generates annoying patterns). There are more advanced dithering methods that create more pleasing results, but they are noticeably slower. The primary concept for appealing dithering result is error diffusion, and the Floyd-Steinberg algorithm is a common realization of that idea.

Even in case you need to choose a general purpose fixed palette, you can optimize the palette for having their colors chosen for approximately equal visual difference (more shades of green than shades of blue, more bright colors than dark colors), or for equal spacing of the RGB values. The former choice allows way better pictures, but requires slow algorithms for color mapping (in case of 16bpp->8bpp, you can cache that mapping in a lookup table), often resorting to brute force searching. The latter one makes finding the appropriate color index from the high-color RGB values and dithering correctly more easy.

If there are no needs for superior quality, you go with a fixed numerically generated palette (commonly 6 shades of each red, green and blue, the "web-safe palette" or 8 shades of both red and green combined with 4 shades of blue), and you apply no dithering or very simple regular dithering algorithms (like "round up the odd pixels, round down the even pixels"). This approach is easy and creates the "run-of-the-mill 8-bit pictures" we know today. Anything better requires more effort and is thus more expensive to create. Good quality 8-bit pictures is no goal commercial vendors of today want to spend resources (money, time, know-how) on. Customers just are expected to run high-color or true color video modes.

On the other hand, in the late 90s, picture quality of an encyclopedia like encarta was a major selling point, and graphics card with insufficient video memory and bus bandwidth for making high-color modes useful general-purpose modes were still common, so the big vendors spent considerable resources on generating quality 8-bit images.

Just as a commenter said in the comments: Software like GIMP still have a dedicated "convert to indexed" function that allows choosing the methods used. The choice has a major influence on processing time and image quality. "Save as 8-bit" in software like MS paint likely uses the most simple approach possible, though.

  • 1
    You forgot the first key step: deciding upon an image and color scheme that can be represented effectively with the available color palette. For example, in a waterscape, one may choose the colors of the water such that the wave highlights of the waves match parts of the sky.
    – supercat
    Mar 1 at 16:01
  • 1
    The last sentence in the 4th paragraph appears to make a distinction between dithering and error diffusion when in fact error diffusion (e.g. Floyd-Steinberg dithering) is a type of dithering. Mar 1 at 19:22
  • 1
    @snips-n-snails Thanks for your comment. Indeed, I didn't mean to make that distinction. I fixed the anser. Mar 1 at 19:33
  • Is there a video encoding that uses 8-bit values along with a dynamically changing palette? Mar 3 at 13:30
  • 1
    @ThorbjørnRavnAndersen of course. Take a look at one of the classic video format of the early 90s (FLI / FLC): drdobbs.com/windows/the-flic-file-format/184408954 Mar 3 at 23:19

An under-appreciated step in making a 256-color picture look really good is adjusting the colors in the source image so that they can fit a good palette. For example, in a real photograph a sky might have a lightness gradient that gets darker toward the horizon, and a hue gradient which is most reddish toward bottom center; trying to represent both gradients may require using over 100 colors on the sky alone. If one paints out the sky and replaces the gradients with a single gradient, however, then it may be possible to get a smooth sky with only 20 palette entries.

Similarly, if one has a room with an light orangish ceiling and a red floor, it may be possible to replace the separate color gradients in the floor and ceiling with overlapping parts of a color gradient that goes from a light orange to a dark red. If one would have been able to afford 15 gradient entries for each, it may be possible to use a 30-color range with ten colors that overlap, thus allowing the use of 20-level gradients rather than 15.

If one needs to represent an existing photograph accurately, 256 colors won't generally be enough to avoid highly visible dither, but if one can adjust the colors of objects so as to fit the available palette, it will be possible to create aesthetically pleasing images with smooth colors.

  • This actually explains a ton. Carefully controlling the image content would do wonders here.
    – Joshua
    Mar 1 at 16:26
  • 4
    @Joshua: Even in the case of actual photos and videos, there can be a lot of luck as to what looks good and what doesn't. Shoot some pictures and video under a variety of lighting conditions, try to convert to 256 colors, and maybe 45% will look decent, 45% terrible, 8% really good, and 2% amazing. Since there's only going to be room for a limited number of pictures or video, shooting a lot more than one is going to use and then throwing out most of the material that isn't really good or amazing won't be a problem.
    – supercat
    Mar 1 at 16:32

The tool pnmcolormap in the Netpbm package chooses a set of colors to best represent an image.

Its man page has a good description of the algorithm:

A quantization method is a way to choose which colors, being fewer in number than in the input, you want in the output. pnmcolormap uses Heckbert's 'median cut' quantization method.

This method involves separating all the colors into 'boxes,' each holding colors that represent about the same number of pixels. You start with one box and split boxes in two until the number of boxes is the same as the number of colors you want in the output, and choose one color to represent each box.

When you split a box, you do it so that all the colors in one sub-box are 'greater' than all the colors in the other. 'Greater,' for a particular box, means it is brighter in the color component (red, green, blue) which has the largest spread in that box. pnmcolormap gives you two ways to define 'largest spread.': 1) largest spread of brightness; 2) largest spread of contribution to the luminosity of the color. E.g. red is weighted much more than blue. Select among these with the -spreadbrightness and -spreadluminosity options. The default is -spreadbrightness.

pnmcolormap provides three ways of choosing a color to represent a box: 1) the center color - the color halfway between the greatest and least colors in the box, using the above definition of 'greater'; 2) the mean of the colors (each component averaged separately by brightness) in the box; 3) the mean weighted by the number of pixels of a color in the image.

Note that in all three methods, there may be colors in the output which do not appear in the input at all.

After mapping the image to the produced color map using Floyd-Steinberg dithering, which does not produce that cross-stitch effect of ordered dithering, the 256-colormapped result is virtually indistinguishable from the original.


If we are talking about 256 or 16 color VGA modes then they are not 256 or 16 colors really but 2^(6+6+6) = 2^18 = 262144 color depth but can use only 256 or 16 different colors in single frame (without additional techniques).

To convert truecolor/higcolor images into 8bit indexed ones there are 2 basic approaches:

which can be combined together to get even better results.

On top of that some HW platforms allows to break the designed limits and improve things like increase resolution or even color depth ...

for example on ZX: multitech , or double y resolution by switching frames (I did that a lot)...

on PC: there was UniVBE that could provide better resolution even hi/true color depth on old 256 color cards (I remember my 256c Trident did work well in high color as the 6bit DACs had to be there anyway) just by exchanging VGA BIOS with their own (you just started it in autoexec.bat and that was it)...

The frame switching method is applicable on VGA too as human eye integrates color (its like dithering but in time instead of space).

Palette based sprite engines could do similar stuff to this

Here another example of (ordered) dithering going to extremes on B&W low resolution displays I am using on MCUs for 3D polygonal rendering


The best digital artists of the day were working in 256-color art

I think much of the answer is that the best digital artists of the day were working in the medium of 8-bit paletted art. These people were experts in choosing palettes, applying dithering, and placing pixels.

A big decider in the visual "feel" of video games (and other applications like Encarta) from this era was the choice of the underlying palette, which was often used throughout the work. Another option was segmenting the palette: using different portions of the 256-color palette for different parts of the image. There would often be separate segments for the game characters and game backgrounds, so that the character graphics could remain the same while optimized sub-palettes could be used for the background of each level, giving a unique feel.

In many games, the palette was designed to allow changes in lighting, which was also sometimes applied for translucency (shadows, smoke, clouds) and blending. The Doom palette is an example where changes in lighting could be captured through defined mappings of palette colors.

Palette changes were often used in artwork and video games for particular effects. Flowing water or lava was often represented by cycling the palette. Some really fantastic artwork created by Mark J. Ferrari (illustrator for LucasArts games such as Loom and The Secret of Monkey Island) using cycling palette techniques has been reproduced.

Some of these artistic techniques have been lost, or the artists that developed skills in them have moved onto other mediums (such as 24-bit color artwork). While you can use tools such as GIMP to convert 24-bit color images to 8-bit color, you are unlikely to be able to do better than talented artists with 1000s of hours of experience with 256-color art.


It seems as if the premise here is wrong to start with:

Why are the converters immediately at our fingertips so bad and how could they be good?

Just take GIMP, a free software, ready immediately at your finger tips, import a 24bpp image and reduce it to 8, and you'll get a great looking one.

And the same is of course true by rendering JPEG onto 8 bit output.

  • 3
    In the '90s, my results were the following: Coral Draw: needed a manual but none was available. Gimp: inoperable piece of trash; paint, etc: you know the drill; however some scanner drivers were able to do a decent job of scanning photos directly to 256 color images some of the time. Paint Shop Pro and ImageMagick were not encountered.
    – Joshua
    Mar 1 at 17:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.