PNG's compression is among the best that can be had without losing image
data and without paying patent or other licensing fees.[5]
Patents are primarily of concern
to application developers, not end users, but the decision to throw away
some of the information in an image is very much an end-user concern. This
information loss generally happens in two ways: in the use of a lesser pixel
depth than is required to represent all of the colors in the image, and in
the actual compression method (hence ``lossy'' compression).
PNG supports all three of the main image types discussed earlier:
truecolor, grayscale, and palette-based. TIFF likewise supports all three;
JPEG only the first two; and GIF only the third, although it can fake
grayscale by using a gray palette. Both GIF and PNG
palettes are limited to a maximum of 256 colors, which means that full-color
images--which usually have tens of thousands or even hundreds of thousands
of colors--cannot be stored as GIFs or palette-based PNGs without loss.[6]
On the other hand, an image that does fit into a 256-color palette requires
only one byte per pixel, which leads to an immediate factor-of-three reduction
in file size over a full RGB image before any ``real'' compression is done
at all. This fact alone
is an important issue for PNG images, since PNG allows
an image to be stored either way.
It is worth mentioning that TIFF palettes support up to 65,536 colors, which is
sufficient to handle many full-color images without loss. Any palette with
more than 256 colors will require two bytes per pixel, eliminating much of the
benefit of a palette-based image, but applications that support TIFF are
usually more concerned with reading and writing speed than with file sizes.
So let's assume that the image type has been decided; that brings us to the
compression method itself. Both GIF and PNG use completely lossless
compression engines, and all but the most recently specified forms of TIFF do
so as well. Standard JPEG compression is always lossy, however, even at the
highest quality settings.[7]
Because of this, JPEG images are usually three to ten
times smaller than the corresponding PNG or TIFF images. This makes JPEG a
very appealing choice for the Web, where small file sizes are important, but
JPEG's compression method can introduce visible artifacts such as blockiness,
color shifts, and ``ringing'' or ``echos'' near image features with sharp
edges. The upshot is that JPEG is a poor choice for intermediate saves during
editing, and for web use it is best suited to smoothly varying truecolor
images, especially photographic ones, at relatively high quality settings.
It is not well suited to simple computer graphics, cartoons, and many types
of synthetic images. Figure C-3 in the color insert demonstrates this:
notice the dirty (or ``noisy'') appearance of the blue-on-white text, the
faint yellow spots above and below it, the darker blue spots in the upper
half, and the hints of pink in the white-on-blue text.
Among the popular lossless image-compression engines, PNG's engine is
demonstrably the most effective--even leaving aside the issue of
prefiltering, which I'll discuss in the next section. TIFF's best classic
compression method and GIF's (only) method are both based on an algorithm
known as LZW (Lempel-Ziv-Welch),
which is quite fast and was used in the Unix utility
compress and in the early PC archiver ARC. PNG's method is called
deflate, and it is used in the Unix utility gzip (which
supplanted compress in the Unix world) and in PKZIP (which replaced
ARC in the early 1990s as the preeminent PC archiver). Unlike LZW, deflate
supports different levels of compression versus speed--a dial, if you will.
At its lowest setting,[8]
deflate is as fast as or faster than LZW and compresses roughly the same; at its
highest setting, deflate is considerably slower but achieves noticeably better
compression. (Decompression speed is essentially unaffected by the compression
level, except insofar as a less compressed image may take more time to read
from network or disk.) The deflate algorithm is described in more detail in
Chapter 9, "Compression and Filtering".