General JPEG Questions and Answers

[These questions and answers are taken almost verbatim from the text of the JPEG Frequently Asked Questions list, maintained by Tom Lane.  A lot of the information contained here does not pertain very specifically to JPEGView, but rather to the current state of JPEG standards and to the Independent JPEG GroupÕs free software.  The latter consists of two general conversion programs: cjpeg, which converts files to JPEG; and djpeg, which converts files from JPEG.  (JPEG Convert, a Macintosh version of cjpeg/djpeg, is available from many archive sites.)  Note that references to compression quality factors in this section refer to cjpeg and djpeg, which use a scale running from 0 to 100, rather than from 0.00 to 4.00 as does AppleÕs QuickTime.  For more information about JPEG in general or the free JPEG software in particular, contact the Independent JPEG Group at jpeg-info@uunet.uu.net.]


What is JPEG?

JPEG (pronounced Òjay-pegÓ) is a standardized image compression mechanism.  JPEG stands for Joint Photographic Experts Group, the original name of the committee that wrote the standard.

JPEG is designed for compressing either full-color or gray-scale images of natural, real-world scenes.  It works well on photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or line drawings.  JPEG handles only still images, but there is a related standard called MPEG for motion pictures.

JPEG is Òlossy,Ó meaning that the decompressed image isnÕt quite the same as the one you started with.  (There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.)  JPEG is designed to exploit known limitations of the human eye, notably the fact that small color details arenÕt perceived as well as small details of light-and-dark.  Thus, JPEG is intended for compressing images that will be looked at by humans.  If you plan to machine-analyze your images, the small errors introduced by JPEG may be a problem for you, even if they are invisible to the eye.

A useful property of JPEG is that the degree of lossiness can be varied by adjusting compression parameters.  This means that the image maker can trade off file size against output image quality.  You can make extremely small files if you donÕt mind poor quality; this is useful for applications like indexing image archives.  Conversely, if you arenÕt happy with the output quality at the default compression setting, you can jack up the quality until you are satisfied, and accept lesser compression.


Why use JPEG?

There are two good reasons: to make your image files smaller, and to store 24-bit-per-pixel color data instead of 8-bit-per-pixel data.

Making image files smaller is a big win for transmitting files across networks and for archiving libraries of images.  Being able to compress a 2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in disk space and transmission time!

If your viewing software doesnÕt support JPEG directly, youÕll have to convert JPEG to some other format for viewing or manipulating images.  Even with a JPEG-capable viewer, it takes longer to decode and view a JPEG image than to view an image of a simpler format such as GIF.  Thus, using JPEG is essentially a time/space tradeoff: you give up some time in order to store or transmit an image more cheaply.

ItÕs worth noting that when network or phone transmission is involved, the time savings from transferring a shorter file can be greater than the extra time needed to decompress the file.

The second fundamental advantage of JPEG is that it stores full color information: 24 bits/pixel (16 million colors).  GIF, the other image format widely used on the networks, can only store 8 bits/pixel (256 or fewer colors). GIF is reasonably well matched to inexpensive computer displays Ñ most run-of-the-mill PCs canÕt display more than 256 distinct colors at once. But full-color hardware is getting cheaper all the time, and JPEG images look much better than GIFs on such hardware.  Within a couple of years, 8-bit GIF will seem as obsolete as black-and-white MacPaint format does today.  Furthermore, for reasons detailed below, JPEG is far more useful than GIF for exchanging images among people with widely varying display hardware.  Hence JPEG is considerably more appropriate than GIF for use as an image exchange standard.

A lot of people are scared off by the term Òlossy compressionÓ.  But when it comes to representing real-world scenes, no digital image format can retain all the information that impinges on your eyeball.  In comparison with the real-world scene, JPEG loses far less information than GIF.  The technical meaning of ÒlossyÓ has nothing to do with this, though; it refers to loss of information over repeated compression cycles, a problem that you may or may not care about.  (If you do, see below.)


When should I use JPEG, and when should I stick with GIF?

JPEG is not going to displace GIF entirely; for some types of images, GIF is superior in image quality, file size, or both.  One of the first things to learn about JPEG is which kinds of images to apply it to.

Generally speaking, JPEG is superior to GIF for storing full-color or gray-scale images of ÒrealisticÓ scenes; that means scanned photographs and similar material.  Any continuous variation in color, such as occurs in highlighted or shaded areas, will be represented more faithfully and in less space by JPEG than by GIF.

GIF does significantly better on images with only a few distinct colors, such as line drawings and simple cartoons.  Not only is GIF lossless for such images, but it often compresses them more than JPEG can.  For example, large areas of pixels that are all exactly  the same color are compressed very efficiently indeed by GIF.  JPEG canÕt squeeze such data as much as GIF does without introducing visible defects.  (One implication of this is that large single-color borders are quite cheap in GIF files, while they are best avoided in JPEG files.)

Computer-drawn images (ray-traced scenes, for instance) usually fall between photographs and cartoons in terms of complexity.  The more complex and subtly rendered the image, the more likely that JPEG will do well on it. The same goes for semi-realistic artwork (fantasy drawings and such).

JPEG has a hard time with very sharp edges: a row of pure-black pixels adjacent to a row of pure-white pixels, for example.  Sharp edges tend to come out blurred unless you use a very high quality setting.  Edges this sharp are rare in scanned photographs, but are fairly common in GIF files: borders, overlaid text, etc.  The blurriness is particularly objectionable with text thatÕs only a few pixels high.  If you have a GIF with a lot of small-size overlaid text, donÕt JPEG it.

Plain black-and-white (two level) images should never be converted to JPEG; they violate all of the conditions given above.  You need at least about 16 gray levels before JPEG is useful for gray-scale images.  It should also be noted that GIF is lossless for gray-scale images of up to 256 levels, while JPEG is not.

If you have a large library of GIF images, you may want to save space by converting the GIFs to JPEG.  This is trickier than it may seem Ñ even when the GIFs contain photographic images, they are actually very poor source material for JPEG, because the images have been color-reduced. Non-photographic images should generally be left in GIF form.  Good-quality photographic GIFs can often be converted with no visible quality loss, but only if you know what you are doing and you take the time to work on each image individually.  Otherwise youÕre likely to lose a lot of image quality or waste a lot of disk spaceÉquite possibly both.  ThereÕs more information below about GIF to JPEG conversion.


How well does JPEG compress images?

Very well indeed, when working with its intended type of image (photographs and suchlike).  For full-color images, the uncompressed data is normally 24 bits/pixel.  The best known lossless compression methods can compress such data about 2:1 on average.  JPEG can typically achieve 10:1 to 20:1 compression without visible loss, bringing the effective storage requirement down to 1 to 2 bits/pixel.  30:1 to 50:1 compression is possible with small to moderate defects, while for very-low-quality purposes such as previews or archive indexes, 100:1 compression is quite feasible.  An image compressed 100:1 with JPEG takes up the same space as a full-color one-tenth-scale thumbnail image, but it retains much more detail than such a thumbnail.

Gray-scale images do not compress by such large factors.  Because the human eye is much more sensitive to brightness variations than to hue variations, JPEG can compress hue data more heavily than brightness (gray-scale) data. A gray-scale JPEG file is generally only about 10%-25% smaller than a full-color JPEG file of similar visual quality.  But the uncompressed gray-scale data is only 8 bits/pixel, or one-third the size of the color data, so the calculated compression ratio is much lower.  The threshold of visible loss is often around 5:1 compression for gray-scale images.

The exact threshold at which errors become visible depends on your viewing conditions.  The smaller an individual pixel, the harder it is to see an error; so errors are more visible on a computer screen (at maybe 70 dots/inch) than on a high-quality color printout (300 or more dots/inch). Thus a higher-resolution image can tolerate more compressionÉwhich is fortunate considering itÕs much bigger to start with.  The numbers quoted above are typical for screen viewing.  Also note that the threshold of visible error varies somewhat across images.


WhatÕs all this hoopla about color quantization?

Most people donÕt have full-color (24 bit per pixel) display hardware. Typical display hardware stores 8 or fewer bits per pixel, so it can display 256 or fewer 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.  JPEGView calls it Òcolor reductionÓ.)

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 algorithm is a black art, and no single algorithm is best for all images.

Since JPEG is a full-color format, converting a color JPEG image for display 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.  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 does have 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 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 have to quantize again to further reduce the number of colors (which results in much poorer image quality than if you had quantized 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 (there is a lot of active research in this area), 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 growing number of people have better-than-8-bit display hardware already: 15-bit Òhi-colorÓ PC displays, true 24-bit displays on workstations and Macintoshes, etc.  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 images in a machine-independent fashion.


What are some rules of thumb for converting GIF images to JPEG?

Converting GIF files to JPEG is a tricky business Ñ you are piling one set of limitations atop a quite different set, and the results can be awful. Certainly a JPEG made from a GIF will never be as good as a JPEG made from true 24-bit color data.  But if what youÕve got is GIFs, and you need to save space, here are some hints for getting the best results.

With care and a clean source image, itÕs often possible to make a JPEG of quality equivalent to the GIF.  This does not mean that the JPEG looks identical to the GIF Ñ it probably wonÕt on an 8-bit display, because the color quantization process used to display the JPEG wonÕt exactly match the GIFÕs quantization.  (See previous item for more about that.)  But given a good viewer, the JPEG will look as good as the GIF.  Some people claim that on 24-bit displays, a carefully converted JPEG can look better than the GIF source, because dither patterns have been eliminated.  (More about dithering in a moment.)

On the other hand, JPEG conversion will degrade an unsuitable image or one that is converted carelessly.  If you are not willing to take the amount of trouble suggested below, youÕre much better off leaving your GIF images alone.  Simply cranking the JPEG quality setting up to a very high value wastes space (which defeats the whole point of the exerciseÉ) and some images will be degraded anyway.

The first rule is never to convert an image thatÕs not appropriate for JPEG. Large, high-visual-quality photographic images are usually the best material.  And they take up lots of space in GIF form, so they offer significant potential space savings.  (A good rule of thumb is not to bother converting any GIF thatÕs much under 100 Kbytes; the potential space savings isnÕt worth the hassle.)

The second rule is to look at each JPEG, to make sure you are happy with it, before throwing away the corresponding GIF; this will give you a chance to re-do the conversion with a higher quality setting if necessary.  Also compare the file sizes Ñ if the image isnÕt suitable JPEG material, a JPEG file of reasonable quality may come out larger than the GIF.

The third rule is to get rid of the border.  Many people have developed an odd habit of putting a large single-color border around a GIF image. While useless, this is nearly free in terms of storage cost in GIF files. It is not free in JPEG files, either in storage space or in decoding time; and the sharp border boundary can create visible artifacts (ÒghostÓ edges). Furthermore, when viewing a bordered JPEG on an 8-bit display, the quantizer will think the border color is important because thereÕs so much of it, and hence will waste color palette entries on the border, thus actually reducing the displayed quality of the main part of the image!  So do yourself a favor and crop off any border before JPEGing.

Gray-scale images usually convert without much problem.  When using cjpeg, be sure to specify -gray.  (By default, cjpeg treats GIFs as color files; this works but wastes space and time for gray-scale data.)  Quality settings around the default (75) are usually fine.

Color images are much trickier.  Color GIFs of photographic images are usually ÒditheredÓ to fool your eye into seeing more than the 256 colors that GIF can actually store.  If you enlarge the image, you will find that adjacent pixels are often of significantly different colors; at normal size the eye averages these pixels together to produce the illusion of an intermediate color value.  The trouble with dithering is that, to JPEG, it looks like high-spatial-frequency color noise; and JPEG canÕt compress noise very well.  The resulting JPEG file is both larger and of lower image quality than what you would have gotten from JPEGing the original full color image (if you had it).  To get around this, you need to ÒsmoothÓ the GIF image before compression.  Smoothing averages together nearby pixels, thus approximating the color that you thought you saw anyway, and in the process getting rid of the rapid color changes that give JPEG trouble.  Proper use of smoothing will both reduce the size of the compressed file and give you a better-looking output image than youÕd get without smoothing.

With the free JPEG software (or programs based on it), a simple smoothing capability is built in.  Try Ò-smooth 10Ó or so when converting GIFs. Values of 10 to 25 seem to work well for high-quality GIFs.  Heavy-handed dithering may require larger smoothing factors.  (If you can see regular fine-scale patterns on the GIF image even without enlargement, then strong smoothing is definitely called for.)  Too large a smoothing factor will blur the output image, which you donÕt want.  If you are an image processing wizard, you can also do smoothing with a separate filtering program, but appropriate use of such tools is beyond the scope of this article.

Quality settings around 85 (a bit higher than default) usually work well when converting color GIFs, assuming that youÕve picked a good smoothing factor.  You may need to go higher if you canÕt hide the dithering pattern with a reasonable smoothing factor.  Really badly dithered GIFs are best left as GIFs.

DonÕt expect JPEG files converted from GIFs to be as small as those created directly from full-color originals.  You wonÕt be able to smooth away all of the dithering noise without ruining the image, and this noise wastes space. Typically, a good-quality converted JPEG will be 1/2 to 1/3rd the size of the GIF file, not 1/4th as suggested above.  (If the JPEG comes out much more than half the size of the GIF, this is a good sign that the image shouldnÕt be converted at all.)

The upshot of all this is that Òcjpeg -quality 85 -smooth 10Ó is probably a good starting point for converting color GIFs.  But if you care about the image, youÕll want to check the results and maybe try a few other settings. Blindly converting a large GIF library at this or any other setting is a recipe for disaster.


Does loss accumulate with repeated compression/ decompression?

It would be nice if, having compressed an image with JPEG, you could decompress it, manipulate it (crop off a border, say), and recompress it without any further image degradation beyond what you lost initially. Unfortunately this is not the case.  In general, recompressing an altered image loses more information.  Hence itÕs important to minimize the number of generations of JPEG compression between initial and final versions of an image.

It turns out that if you decompress and recompress an image at the same quality setting first used, little or no further degradation occurs. (Counterintuitively, this works better the lower the quality setting. But you must use exactly the same setting, or all bets are off.) This means that you can make local modifications to an image without material degradation of other areas of the image.  

Unfortunately, cropping doesnÕt count as a local change!  JPEG processes the image in small blocks, and cropping usually moves the block boundaries, so that the image looks completely different to JPEG.  You can take advantage of the low-degradation behavior if you are careful to crop the top and left margins only by a multiple of the block size (typically 16 pixels), so that the remaining blocks start in the same places.

The bottom line is that JPEG is a useful format for archival storage and transmission of images, but you donÕt want to use it as an intermediate format for sequences of image manipulation steps.  Use a lossless format (uncompressed PICT, TIFF, etc) while working on the image, then JPEG it when you are ready to file it away.  Aside from avoiding degradation, you will save a lot of compression/decompression time this wayÉ


Why all the argument about file formats?

Strictly speaking, JPEG refers only to a family of compression algorithms; it does not refer to a specific image file format.  The JPEG committee was prevented from defining a file format by turf wars within the international standards organizations.

Since we canÕt actually exchange images with anyone else unless we agree on a common file format, this leaves us with a problem.  In the absence of official standards, a number of JPEG program writers have just gone off to Òdo their own thingÓ, and as a result their programs arenÕt compatible with anybody elseÕs.

The closest thing we have to a standard JPEG format is some work thatÕs been coordinated by people at C-Cube Microsystems.  They have defined two JPEG-based file formats:
    ¥ JFIF (JPEG File Interchange Format), a Òlow-endÓ format that transports pixels and not much else.
    ¥ TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format.  TIFF is a Òhigh-endÓ format that will let you record just about everything you ever wanted to know about an image, and a lot more besides.  TIFF is a lot more complex than JFIF, and is generally less transportable, because different vendors have often implemented slightly different and incompatible subsets of TIFF.

Both of these formats were developed with input from all the major vendors of JPEG-related products; itÕs reasonably likely that future commercial products will adhere to one or both standards.

JFIF has emerged as the de-facto standard.  JFIF is simpler than TIFF and is available now; the TIFF 6.0 spec has only recently been officially adopted, and it is still unusably vague on some crucial details. Even when TIFF/JPEG is well defined, the JFIF format is likely to be a widely supported lowest common denominator; TIFF/JPEG files may never be as transportable.

In the Macintosh world, all images are supposed to appear in AppleÕs standard PICT format.  QuickTimeÕs JPEG compressor actually produces a JFIF-compatible data sequence with a PICT ÒwrapperÓ around it.  Conversion between PICT/JPEG and JFIF is thus a fairly simple matter of adding or removing the ÒwrapperÓ. JPEGView and several other Macintosh programs can do this for you.  But non-Macintosh computers donÕt know anything about PICT, so be sure to convert a PICT/JPEG file to JFIF format before giving it to anyone who uses a non-Macintosh computer.

Just to muddy the waters, there are a couple of proprietary JPEG-based file formats to worry about.  One that you are likely to find on some BBS systems is Handmade Software, Inc.Õs ÒHSIÓ format.  ThereÕs no way to read HSI files except by using HSIÕs software Ñ which runs only on PCs.  About all you can do is try to persuade the BBS operator to convert to the standardized, public-domain JFIF format.


IsnÕt there a lossless JPEG?

ThereÕs a great deal of confusion on this subject.  The JPEG committee did define a truly lossless compression algorithm (i.e., one that guarantees the final output is bit-for-bit identical to the original input).  However, this lossless mode has almost nothing in common with the regular lossy JPEG algorithm, and it offers much less compression.  At present, very few implementations of lossless JPEG exist.

Lossless JPEG typically compresses full-color data by around 2:1.  Lossless JPEG works well only on continuous-tone images; it does not provide useful compression of palette-color images or low-bit-depth images.  (The JBIG standard is considered superior to lossless JPEG for images of less than 6 bits/sample.)

Cranking a regular JPEG implementation up to its maximum quality setting does not get you a lossless image.  Even at the maximum possible quality setting, regular JPEG is not lossless, because it is subject to roundoff errors in various calculations.  Roundoff errors are nearly always too small to be seen, but they will accumulate if you put the image through multiple cycles of compression.

Many implementations wonÕt even let you get to the maximum possible setting, because itÕs such an inefficient way to use regular JPEG.  With the IJG JPEG software, for example, you have to say not only Ò-quality 100Ó but also Ò-sample 1x1Ó to eliminate all deliberate loss of information.  The resulting files are far larger and of only fractionally better quality than files generated at more reasonable settings.  If you really need lossless storage, donÕt try to approximate it with regular JPEG.