Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

JPEG image compression FAQ, part 1/2
Section - [8] What is color quantization?

( Part1 - Part2 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum archive ]


Top Document: JPEG image compression FAQ, part 1/2
Previous Document: [7] How do I view JPEG images posted on Usenet?
Next Document: [9] What are some rules of thumb for converting GIF images to JPEG?
See reader questions & answers on this topic! - Help others by sharing your knowledge
Many people don't have full-color (24 bit per pixel) display hardware.
Inexpensive display hardware stores 8 bits per pixel, so it can display
at most 256 distinct colors at a time.  To display a full-color image, the
computer must choose an appropriate set of representative colors and map
the image into these colors.  This process is called "color quantization".
(This is something of a misnomer; "color selection" or "color reduction"
would be a better term.  But we're stuck with the standard usage.)

Clearly, color quantization is a lossy process.  It turns out that for most
images, the details of the color quantization algorithm have *much* more
impact on the final image quality than do any errors introduced by JPEG
itself (except at the very lowest JPEG quality settings).  Making a good
color quantization method is a black art, and no single algorithm is best
for all images.

Since JPEG is a full-color format, displaying a color JPEG image on
8-bit-or-less hardware requires color quantization.  The speed and image
quality of a JPEG viewer running on such hardware are largely determined by
its quantization algorithm.  Depending on whether a quick-and-dirty or
good-but-slow method is used, you'll see great variation in image quality
among viewers on 8-bit displays, much more than occurs on 24-bit displays.

On the other hand, a GIF image has already been quantized to 256 or fewer
colors.  (A GIF always has a specific number of colors in its palette, and
the format doesn't allow more than 256 palette entries.)  GIF has the
advantage that the image maker precomputes the color quantization, so
viewers don't have to; this is one of the things that make GIF viewers
faster than JPEG viewers.  But this is also the *disadvantage* of GIF:
you're stuck with the image maker's quantization.  If the maker quantized to
a different number of colors than what you can display, you'll either waste
display capability or else have to requantize to reduce the number of colors
(which usually results in much poorer image quality than quantizing once
from a full-color image).  Furthermore, if the maker didn't use a
high-quality color quantization algorithm, you're out of luck --- the image
is ruined.

For this reason, JPEG promises significantly better image quality than GIF
for all users whose machines don't match the image maker's display hardware.
JPEG's full color image can be quantized to precisely match the viewer's
display hardware.  Furthermore, you will be able to take advantage of future
improvements in quantization algorithms, or purchase better display
hardware, to get a better view of JPEG images you already have.  With a GIF,
you're stuck forevermore with what was sent.

A closely related problem is seen in many current World Wide Web browsers:
when running on an 8-bit display, they force all images into a pre-chosen
palette.  (They do this to avoid having to worry about how to allocate the
limited number of available color slots among the various items on a Web
page.)  A GIF version of a photo usually degrades very badly in this
situation, because it's effectively being forced through a second
quantization step.  A JPEG photo won't look wonderful either, but it will
look less bad than the GIF equivalent because it's been quantized only once.

A growing number of people have better-than-8-bit display hardware already:
15- or 16-bit/pixel "high color" displays are now quite common, and true
24-bit/pixel displays are no longer rare.  For these people, GIF is already
obsolete, as it cannot represent an image to the full capabilities of their
display.  JPEG images can drive these displays much more effectively.

In short, JPEG is an all-around better choice than GIF for representing
photographic images in a machine-independent fashion.


It's sometimes thought that a JPEG converted from a GIF shouldn't require
color quantization.  That is false; even when you feed a 256-or-less-color
GIF into JPEG, what comes out of the decompressor is not 256 colors, but
thousands of colors.  This happens because JPEG's lossiness affects each
pixel a little differently, so two pixels that started with identical colors
will usually come out with slightly different colors.  Considering the whole
image, each original color gets "smeared" into a cluster of nearby colors.
Therefore quantization is always required to display a color JPEG on a
colormapped display, regardless of the image source.

The same effect makes it nearly meaningless to talk about the number of
colors used by a JPEG image.  Even if you tried to count the number of
distinct pixel values, different JPEG decoders would give you different
results because of roundoff error differences.  I occasionally see posted
images described as "256-color JPEG".  This tells me that the poster
(a) hasn't read this FAQ and (b) probably converted the JPEG from a GIF.
JPEGs can be classified as color or gray-scale, but number of colors just
isn't a useful concept for JPEG, any more than it is for a real photograph.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: JPEG image compression FAQ, part 1/2
Previous Document: [7] How do I view JPEG images posted on Usenet?
Next Document: [9] What are some rules of thumb for converting GIF images to JPEG?

Part1 - Part2 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
jpeg-info@uunet.uu.net





Last Update March 27 2014 @ 02:11 PM