home *** CD-ROM | disk | FTP | other *** search
Text File | 1999-03-29 | 58.3 KB | 1,078 lines |
- Newsgroups: comp.graphics.misc,comp.infosystems.www.authoring.images,comp.answers,news.answers
- Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hecate.umd.edu!haven.umd.edu!purdue!mozo.cc.purdue.edu!news.iupui.edu!news.indiana.edu!vixen.cso.uiuc.edu!uwm.edu!logbridge.uoregon.edu!newsfeed.berkeley.edu!newsfeed.enteract.com!ix.netcom.com!tgl
- From: tgl@netcom.com (Tom Lane)
- Subject: JPEG image compression FAQ, part 1/2
- Message-ID: <jpeg-faq-p1_922674260@netcom.com>
- Followup-To: comp.graphics.misc
- Summary: General questions and answers about JPEG
- Keywords: JPEG, image compression, FAQ, JPG, JFIF
- Supersedes: <jpeg-faq-p1_921456839@netcom.com>
- Reply-To: jpeg-info@uunet.uu.net
- Organization: Independent JPEG Group
- Date: Mon, 29 Mar 1999 02:24:27 GMT
- Approved: news-answers-request@MIT.Edu
- Expires: Mon, 26 Apr 1999 02:24:20 GMT
- Lines: 1059
- Sender: tgl@netcom17.netcom.com
- Xref: senator-bedfellow.mit.edu comp.graphics.misc:39157 comp.infosystems.www.authoring.images:33421 comp.answers:35587 news.answers:154476
-
- Archive-name: jpeg-faq/part1
- Posting-Frequency: every 14 days
- Last-modified: 28 March 1999
-
- This article answers Frequently Asked Questions about JPEG image compression.
- This is part 1, covering general questions and answers about JPEG. Part 2
- gives system-specific hints and program recommendations. As always,
- suggestions for improvement of this FAQ are welcome.
-
- New since version of 14 March 1999:
- * Expanded item 10 to discuss lossless rotation and cropping of JPEGs.
-
-
- This article includes the following sections:
-
- Basic questions:
-
- [1] What is JPEG?
- [2] Why use JPEG?
- [3] When should I use JPEG, and when should I stick with GIF?
- [4] How well does JPEG compress images?
- [5] What are good "quality" settings for JPEG?
- [6] Where can I get JPEG software?
- [7] How do I view JPEG images posted on Usenet?
-
- More advanced questions:
-
- [8] What is color quantization?
- [9] What are some rules of thumb for converting GIF images to JPEG?
- [10] Does loss accumulate with repeated compression/decompression?
- [11] What is progressive JPEG?
- [12] Can I make a transparent JPEG?
- [13] Isn't there a lossless JPEG?
- [14] Why all the argument about file formats?
- [15] How do I recognize which file format I have, and what do I do about it?
- [16] What other common compatibility problems are there?
- [17] How does JPEG work?
- [18] What about arithmetic coding?
- [19] Could an FPU speed up JPEG? How about a DSP chip?
- [20] Isn't there an M-JPEG standard for motion pictures?
- [21] What if I need more than 8-bit precision?
- [22] How can my program extract image dimensions from a JPEG file?
-
- Miscellaneous:
-
- [23] Where can I learn about using images on the World Wide Web?
- [24] Where are FAQ lists archived?
-
-
- This article and its companion are posted every 2 weeks. If you can't find
- part 2, you can get it from the news.answers archive at rtfm.mit.edu
- (see "[24] Where are FAQ lists archived?"). Part 2 changes very frequently;
- get a new copy if the one you are reading is more than a couple months old.
-
- ------------------------------
-
- Subject: [1] 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 changes are perceived less accurately than
- small changes in brightness. 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 such
- as 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.
-
- Another important aspect of JPEG is that decoders can trade off decoding
- speed against image quality, by using fast but inaccurate approximations to
- the required calculations. Some viewers obtain remarkable speedups in this
- way. (Encoders can also trade accuracy for speed, but there's usually less
- reason to make such a sacrifice when writing a file.)
-
- ------------------------------
-
- Subject: [2] 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 win for transmitting files across networks
- and for archiving libraries of images. Being able to compress a 2 Mbyte
- full-color file down to, say, 100 Kbytes makes a big difference in disk
- space and transmission time! And JPEG can easily provide 20:1 compression
- of full-color data. If you are comparing GIF and JPEG, the size ratio is
- usually more like 4:1 (see "[4] How well does JPEG compress images?").
-
- Now, 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. But it's worth noting that when network transmission is
- involved, the time savings from transferring a shorter file can be greater
- than the 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 net, 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 photos
- look *much* better than GIFs on such hardware. Within a couple of years,
- GIF will probably seem as obsolete as black-and-white MacPaint format does
- today. Furthermore, JPEG is far more useful than GIF for exchanging images
- among people with widely varying display hardware, because it avoids
- prejudging how many colors to use (see "[8] What is color quantization?").
- Hence JPEG is considerably more appropriate than GIF for use as a Usenet
- and World Wide Web standard photo format.
-
- 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. By comparison
- with the real-world scene, JPEG loses far less information than GIF.
- The real disadvantage of lossy compression is that if you repeatedly
- compress and decompress an image, you lose a little more quality each time
- (see "[10] Does loss accumulate with repeated compression/decompression?").
- This is a serious objection for some applications but matters not at all
- for many others.
-
- ------------------------------
-
- Subject: [3] 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,
- continuous-tone artwork, and similar material. Any smooth 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, such as ray-traced scenes, 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).
- But icons that use only a few colors are handled better by GIF.
-
- 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:
- consider 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. (If you want to
- attach descriptive text to a JPEG image, put it in as a comment rather than
- trying to overlay it on the image. Most recent JPEG software can deal with
- textual comments in a JPEG file, although older viewers may just ignore the
- comments.)
-
- 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. Read sections 8 and 9
- if you want to convert GIFs to JPEG.
-
- ------------------------------
-
- Subject: [4] 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, yet it retains much more detail than such a thumbnail.
-
- For comparison, a GIF version of the same image would start out by
- sacrificing most of the color information to reduce the image to 256 colors
- (8 bits/pixel). This provides 3:1 compression. GIF has additional "LZW"
- compression built in, but LZW doesn't work very well on typical photographic
- data; at most you may get 5:1 compression overall, and it's not at all
- uncommon for LZW to be a net loss (i.e., less than 3:1 overall compression).
- LZW *does* work well on simpler images such as line drawings, which is why
- GIF handles that sort of image so well. When a JPEG file is made from
- full-color photographic data, using a quality setting just high enough to
- prevent visible loss, the JPEG will typically be a factor of four or five
- smaller than a GIF file made from the same data.
-
- 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 70 or so
- 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 compression
- ratios quoted above are typical for screen viewing. Also note that the
- threshold of visible error varies considerably across images.
-
- ------------------------------
-
- Subject: [5] What are good "quality" settings for JPEG?
-
- Most JPEG compressors let you pick a file size vs. image quality tradeoff by
- selecting a quality setting. There seems to be widespread confusion about
- the meaning of these settings. "Quality 95" does NOT mean "keep 95% of the
- information", as some have claimed. The quality scale is purely arbitrary;
- it's not a percentage of anything.
-
- In fact, quality scales aren't even standardized across JPEG programs.
- The quality settings discussed in this article apply to the free IJG JPEG
- software (see part 2, item 15), and to many programs based on it. Some
- other JPEG implementations use completely different quality scales.
- For example:
- * Apple used to use a scale running from 0 to 4, not 0 to 100.
- * Recent Apple software uses an 0-100 scale that has nothing to do with
- the IJG scale (their Q 50 is about the same as Q 80 on the IJG scale).
- * Paint Shop Pro's scale is the exact opposite of the IJG scale, PSP
- setting N = IJG 100-N; thus lower numbers are higher quality in PSP.
- * Adobe Photoshop doesn't use a numeric scale at all, it just gives you
- "high"/"medium"/"low" choices. (But I hear this is changing in 4.0.)
- Fortunately, this confusion doesn't prevent different implementations from
- exchanging JPEG files. But you do need to keep in mind that quality scales
- vary considerably from one JPEG-creating program to another, and that just
- saying "I saved this at Q 75" doesn't mean a thing if you don't say which
- program you used.
-
- In most cases the user's goal is to pick the lowest quality setting, or
- smallest file size, that decompresses into an image indistinguishable from
- the original. This setting will vary from one image to another and from one
- observer to another, but here are some rules of thumb.
-
- For good-quality, full-color source images, the default IJG quality setting
- (Q 75) is very often the best choice. This setting is about the lowest you
- can go without expecting to see defects in a typical image. Try Q 75 first;
- if you see defects, then go up.
-
- If the image was less than perfect quality to begin with, you might be able
- to drop down to Q 50 without objectionable degradation. On the other hand,
- you might need to go to a *higher* quality setting to avoid further loss.
- This is often necessary if the image contains dithering or moire patterns
- (see "[9] What are some rules of thumb for converting GIF images to JPEG?").
-
- Except for experimental purposes, never go above about Q 95; using Q 100
- will produce a file two or three times as large as Q 95, but of hardly any
- better quality. Q 100 is a mathematical limit rather than a useful setting.
- If you see a file made with Q 100, it's a pretty sure sign that the maker
- didn't know what he/she was doing.
-
- If you want a very small file (say for preview or indexing purposes) and are
- prepared to tolerate large defects, a Q setting in the range of 5 to 10 is
- about right. Q 2 or so may be amusing as "op art". (It's worth mentioning
- that the current IJG software is not optimized for such low quality factors.
- Future versions may achieve better image quality for the same file size at
- low quality settings.)
-
- If your image contains sharp colored edges, you may notice slight fuzziness
- or jagginess around such edges no matter how high you make the quality
- setting. This can be suppressed, at a price in file size, by turning off
- chroma downsampling in the compressor. The IJG encoder regards downsampling
- as a separate option which you can turn on or off independently of the Q
- setting. With the "cjpeg" program, the command line switch "-sample 1x1"
- turns off downsampling; other programs based on the IJG library may have
- checkboxes or other controls for downsampling. Other JPEG implementations
- may or may not provide user control of downsampling. Adobe Photoshop, for
- example, automatically switches off downsampling at its higher quality
- settings. On most photographic images, we recommend leaving downsampling
- on, because it saves a significant amount of space at little or no visual
- penalty.
-
- For images being used on the World Wide Web, it's often a good idea to
- give up a small amount of image quality in order to reduce download time.
- Quality settings around 50 are often perfectly acceptable on the Web.
- In fact, a user viewing such an image on a browser with a 256-color display
- is unlikely to be able to see any difference from a higher quality setting,
- because the browser's color quantization artifacts will swamp any
- imperfections in the JPEG image itself. It's also worth knowing that
- current progressive-JPEG-making programs use default progression sequences
- that are tuned for quality settings around 50-75: much below 50, the early
- scans will look really bad, while much above 75, the later scans won't
- contribute anything noticeable to the picture.
-
- ------------------------------
-
- Subject: [6] Where can I get JPEG software?
-
- See part 2 of this FAQ for recommendations about programs for particular
- systems. Part 2 also tells where to find free source code for implementing
- JPEG, in case you want to write your own programs using JPEG.
-
- The comp.graphics.* FAQs and the alt.binaries.pictures FAQ are more general
- sources of information about graphics programs available on the Internet
- (see "[24] Where are FAQ lists archived?").
-
- ------------------------------
-
- Subject: [7] How do I view JPEG images posted on Usenet?
-
- Image files posted on the alt.binaries.pictures.* newsgroups are usually
- "uuencoded". Uuencoding converts binary image data into text that can
- safely be posted. Most posters also divide large posts into multiple parts,
- since some news software can't cope with big articles. Before your viewer
- will recognize the image, you must combine the parts into one file and run
- the text through a uudecode program. (This is all true for GIF as well as
- JPEG, by the way.) There are programs available to automate this process.
-
- For more info see the alt.binaries.pictures FAQ, which is available from
- http://www.faqs.org/faqs/pictures-faq/
- (see also "[24] Where are FAQ lists archived?").
-
- ------------------------------
-
- Subject: [8] What is color quantization?
-
- 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.
-
- ------------------------------
-
- Subject: [9] 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
- pixel-for-pixel identical to the GIF --- it won't. Especially not on an
- 8-bit display, because the color quantization process used to display the
- JPEG probably won't quite match the quantization process used to make the
- GIF from the original data (see "[8] What is color quantization?"). But
- remember that the GIF itself is not all that faithful to the full-color
- original, if you look at individual pixels. Looking at the overall image,
- a converted JPEG can look as good as its GIF source. Some people claim that
- on 24-bit displays, a carefully converted JPEG can actually look better than
- the GIF source, because dither patterns have been eliminated. (More about
- dithering in a moment.)
-
- On the other hand, JPEG conversion absolutely *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, no?)
- and some images will be degraded anyway.
-
- The first rule is never to convert an image that's not appropriate for JPEG
- (see "[3] When should I use JPEG, and when should I stick with GIF?").
- Large, high-visual-quality photographic images are usually the best source
- 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 savings isn't
- worth the hassle.)
-
- The second rule is to know where the image came from. Repeated GIF<=>JPEG
- conversions are guaranteed to turn an image into mush, because you pay a
- steep quality price on each round trip. Don't reconvert images that have
- been converted before.
-
- 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.
- Worse, 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.
-
- The final 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.
-
- Gray-scale photos usually convert without much problem. When using cjpeg,
- be sure to use the -gray switch. (Otherwise, cjpeg treats a GIF as color
- data; this works, but it wastes space and time if the image is really only
- gray-scale.) 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 IJG JPEG software (cjpeg or derived programs), 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. GIFs with
- 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 FAQ.
-
- 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 still higher quality settings 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. The dithering noise wastes space, but
- you won't be able to smooth away all the noise without blurring the image.
- Typically, a good-quality converted JPEG will be one-half to one-third the
- size of the GIF file, not one-fourth as suggested in section 4. 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.
-
- ------------------------------
-
- Subject: [10] 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.
-
- There are a few specialized operations that can be done on a JPEG file
- without decompressing it, and thus without incurring the generational loss
- that you'd normally get from loading and re-saving the image in a regular
- image editor. In particular it is possible to do 90-degree rotations and
- flips losslessly, if the image dimensions are a multiple of the file's
- block size (typically 16x16, 16x8, or 8x8 pixels for color JPEGs). This
- fact used to be just an academic curiosity, but it has assumed practical
- importance recently because many users of digital cameras would like to be
- able to rotate their images from landscape to portrait format without
- incurring loss --- and practically all digicams that produce JPEG files
- produce images of the right dimensions for these operations to work. So
- software that can do lossless JPEG transforms has started to pop up. But
- you do need special software; rotating the image in a regular image editor
- won't be lossless.
-
- It turns out that if you decompress and recompress an image at the same
- quality setting first used, relatively little further degradation occurs.
- This means that you can make local modifications to a JPEG image without
- material degradation of other areas of the image. (The areas you change
- will still degrade, however.) Counterintuitively, this works better the
- lower the quality setting. But you must use *exactly* the same setting,
- or all bets are off. Also, the decompressed image must be saved in a
- full-color format; if you do something like JPEG=>GIF=>JPEG, the color
- quantization step loses lots of information.
-
- 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. (True
- lossless cropping is possible under the same restrictions about where to
- crop, but again this requires specialized software.)
-
- The bottom line is that JPEG is a useful format for compact 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 24-bit
- format (PNG, TIFF, PPM, etc) while working on the image, then JPEG it when
- you are ready to file it away or send it out on the net. If you expect to
- edit your image again in the future, keep a lossless master copy to work
- from. The JPEG you put up on your Web site should be a derived copy, not
- your editing master.
-
- ------------------------------
-
- Subject: [11] What is progressive JPEG?
-
- A simple or "baseline" JPEG file is stored as one top-to-bottom scan of the
- image. Progressive JPEG divides the file into a series of scans. The first
- scan shows the image at the equivalent of a very low quality setting, and
- therefore it takes very little space. Following scans gradually improve the
- quality. Each scan adds to the data already provided, so that the total
- storage requirement is roughly the same as for a baseline JPEG image of the
- same quality as the final scan. (Basically, progressive JPEG is just a
- rearrangement of the same data into a more complicated order.)
-
- The advantage of progressive JPEG is that if an image is being viewed
- on-the-fly as it is transmitted, one can see an approximation to the whole
- image very quickly, with gradual improvement of quality as one waits longer;
- this is much nicer than a slow top-to-bottom display of the image. The
- disadvantage is that each scan takes about the same amount of computation to
- display as a whole baseline JPEG file would. So progressive JPEG only makes
- sense if one has a decoder that's fast compared to the communication link.
- (If the data arrives quickly, a progressive-JPEG decoder can adapt by
- skipping some display passes. Hence, those of you fortunate enough to have
- T1 or faster net links may not see any difference between progressive and
- regular JPEG; but on a modem-speed link, progressive JPEG is great.)
-
- Up until recently, there weren't many applications in which progressive JPEG
- looked attractive, so it hasn't been widely implemented. But with the
- popularity of World Wide Web browsers running over slow modem links, and
- with the ever-increasing horsepower of personal computers, progressive JPEG
- has become a win for WWW use. IJG's free JPEG software (see part 2, item
- 15) now supports progressive JPEG, and the capability is spreading fast in
- WWW browsers and other programs.
-
- Except for the ability to provide progressive display, progressive JPEG and
- baseline JPEG are basically identical, and they work well on the same kinds
- of images. It is possible to convert between baseline and progressive
- representations of an image without any quality loss. (But specialized
- software is needed to do this; conversion by decompressing and recompressing
- is *not* lossless, due to roundoff errors.)
-
- A progressive JPEG file is not readable at all by a baseline-only JPEG
- decoder, so existing software will have to be upgraded before progressive
- JPEG can be used widely. See item 16 in part 2 for the latest news about
- which programs support it.
-
- ------------------------------
-
- Subject: [12] Can I make a transparent JPEG?
-
- No. JPEG does not support transparency and is not likely to do so any time
- soon. It turns out that adding transparency to JPEG would not be a simple
- task; read on if you want the gory details.
-
- The traditional approach to transparency, as found in GIF and some other
- file formats, is to choose one otherwise-unused color value to denote a
- transparent pixel. That can't work in JPEG because JPEG is lossy: a pixel
- won't necessarily come out *exactly* the same color that it started as.
- Normally, a small error in a pixel value is OK because it affects the image
- only slightly. But if it changes the pixel from transparent to normal or
- vice versa, the error would be highly visible and annoying, especially if
- the actual background were quite different from the transparent color.
-
- A more reasonable approach is to store an alpha channel (transparency
- percentage) as a separate color component in a JPEG image. That could work
- since a small error in alpha makes only a small difference in the result.
- The problem is that a typical alpha channel is exactly the sort of image
- that JPEG does very badly on: lots of large flat areas and sudden jumps.
- You'd have to use a very high quality setting for the alpha channel. It
- could be done, but the penalty in file size is large. A transparent JPEG
- done this way could easily be double the size of a non-transparent JPEG.
- That's too high a price to pay for most uses of transparency.
-
- The only real solution is to combine lossy JPEG storage of the image
- with lossless storage of a transparency mask using some other algorithm.
- Developing, standardizing, and popularizing a file format capable of
- doing that is not a small task. As far as I know, no serious work is
- being done on it; transparency doesn't seem worth that much effort.
-
- ------------------------------
-
- Subject: [13] Isn't there a lossless JPEG?
-
- There's a great deal of confusion on this subject, which is not surprising
- because there are several different compression methods all known as "JPEG".
- The commonly used method is "baseline JPEG" (or its variant "progressive
- JPEG"). The same ISO standard also defines a very different method called
- "lossless JPEG". And if that's not confusing enough, a new lossless
- standard called "JPEG-LS" is about to hit the streets.
-
- When I say "lossless", I mean mathematically lossless: a lossless
- compression algorithm is one that guarantees its decompressed output is
- bit-for-bit identical to the original input. This is a much stronger claim
- than "visually indistinguishable from the original". Baseline JPEG can
- reach visual indistinguishability for most photo-like images, but it can
- never be truly lossless.
-
- Lossless JPEG is a completely different method that really is lossless.
- However, it doesn't compress nearly as well as baseline JPEG; it typically
- can compress full-color data by around 2:1. And lossless JPEG works well
- only on continuous-tone images. It does not provide useful compression of
- palette-color images or low-bit-depth images.
-
- Lossless JPEG has never been popular --- in fact, no common applications
- support it --- and it is now largely obsolete. (For example, the new PNG
- standard outcompresses lossless JPEG on most images.) Recognizing this,
- the ISO JPEG committee recently finished an all-new lossless compression
- standard called JPEG-LS (you may have also heard of it under the name LOCO).
- JPEG-LS gives better compression than original lossless JPEG, but still
- nowhere near what you can get with a lossy method. It's anybody's guess
- whether this new standard will achieve any popularity.
-
- It's worth repeating that cranking a regular JPEG implementation up to its
- maximum quality setting *does not* get you lossless storage; even at the
- highest possible quality setting, baseline JPEG is lossy because it is
- subject to roundoff errors in various calculations. Roundoff errors alone
- are nearly always too small to be seen, but they will accumulate if you put
- the image through multiple cycles of compression (see section 10).
-
- 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 not only select "quality 100" but also
- turn off chroma downsampling to minimize loss of information. The resulting
- files are far larger and of only fractionally better quality than files
- generated at more reasonable settings. And they're still slightly lossy!
- If you really need lossless storage, don't try to approximate it with
- regular JPEG.
-
- ------------------------------
-
- Subject: [14] 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
- anyone 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 :-).
-
- JFIF has emerged as the de-facto standard on Internet, and is what is most
- commonly meant by "a JPEG file". Most JFIF readers are also capable of
- handling some not-quite-JFIF-legal variant formats.
-
- The TIFF 6.0 spec for incorporating JPEG is not widely implemented, partly
- because it has some serious design flaws. A revised TIFF/JPEG design is now
- described by TIFF Technical Note #2; this design will be the one used in
- TIFF 7.0. New implementations of TIFF should use the Tech Note's design for
- embedding JPEG, not the TIFF 6.0 design. (As far as I know, NeXTStep
- systems are the only ones making any significant use of TIFF 6.0 style
- TIFF/JPEG.) Even when TIFF/JPEG is stable, it will never be as widely used
- as JFIF. TIFF is far more complex than JFIF, and is generally less
- transportable because different vendors often implement slightly different,
- nonoverlapping subsets of TIFF. Adding JPEG to the mix hasn't helped any.
-
- Apple's Macintosh QuickTime software uses a JFIF-compatible datastream
- wrapped inside the Mac-specific PICT format. Conversion between JFIF and
- PICT/JPEG is pretty straightforward, and several Mac programs are available
- to do it (see part 2, item 8). If you have an editor that handles binary
- files, you can even strip a PICT/JPEG file down to JFIF by hand; see the
- next section for details.
-
- News flash: the ISO JPEG committee seems to have won their turf wars. They
- have defined a complete file format spec called SPIFF in the new "Part 3"
- extensions to the JPEG standard. It's pretty late in the game though, so
- whether this will have much impact on real-world files remains to be seen.
- SPIFF is upward compatible with JFIF, so if it does get widely adopted, most
- users probably won't even notice.
-
- ------------------------------
-
- Subject: [15] How do I recognize which file format I have,
- and what do I do about it?
-
- If you have an alleged JPEG file that your software won't read, it's likely
- to be some proprietary JPEG-based format. You can tell what you have by
- inspecting the first few bytes of the file:
-
- 1. A JFIF-standard file will start with the four bytes (hex) FF D8 FF E0,
- followed by two variable bytes (often hex 00 10), followed by 'JFIF'.
-
- 2. If you see FF D8 FF at the start, but not the 'JFIF' marker, you
- probably have a not-quite-JFIF JPEG file. Most JFIF software should
- read it without complaint. If you are using something that is picky
- enough to complain about the lack of a JFIF marker, try another decoder.
- (Both very old JPEG files and very new ones may lack JFIF markers ---
- the new SPIFF standard mentioned above doesn't use a JFIF marker.
- So gripe to your software vendor if you find this to be the problem.)
-
- 3. A Macintosh PICT file, if JPEG-compressed, will have several hundred
- bytes of header (often 726 bytes, but not always) followed by JPEG data.
- Look for the 3-byte sequence (hex) FF D8 FF. The text 'Photo - JPEG'
- will usually appear shortly before this header, and 'AppleMark' or
- 'JFIF' will usually appear shortly after it. Strip off everything
- before the FF D8 FF and you will usually be able to decode the file.
- (This will fail if the PICT image is divided into multiple "bands";
- fortunately banded PICTs aren't very common. A banded PICT contains
- multiple JPEG datastreams whose heights add up to the total image
- height. These need to be stitched back together into one image.
- Bailey Brown has some simple tools for this purpose on a Web page at
- http://www.isomedia.com/homes/bailey/photo-jpeg/photo-jpeg.html.)
-
- 4. If the file came from a Macintosh, it could also be a standard JFIF
- file with a MacBinary header attached. In this case, the JFIF header
- will appear 128 bytes into the file. Get rid of the first 128 bytes
- and you're set.
-
- 5. Anything else: it's a proprietary format, or not JPEG at all. If you
- are lucky, the file may consist of a header and a raw JPEG data stream.
- If you can identify the start of the JPEG data stream (look for FF D8),
- try stripping off everything before that.
-
- At least one release of HiJaak Pro writes JFIF files that claim to be
- revision 2.01. There is no such spec; the latest JFIF revision is 1.02.
- It looks like HiJaak got the high and low bytes backwards. Unfortunately,
- most JFIF readers will give up on encountering these files, because the JFIF
- spec defines a major version number change to mean an incompatible format
- change. If there ever *were* a version 2.01, it would be so numbered
- because current software could not read it and should not try. (One wonders
- if HiJaak has ever heard of cross-testing with other people's software.)
- If you run into one of these misnumbered files, you can fix it with a
- binary-file editor, by changing the twelfth byte of the file from 2 to 1.
-
- ------------------------------
-
- Subject: [16] What other common compatibility problems are there?
-
- Aside from the file format difficulties mentioned in the previous section,
- there are a few other common causes of trouble with transferring JPEGs.
-
- Old decoders that don't handle progressive JPEG will often give rather
- cryptic error messages when fed a progressive JPEG. If you get a complaint
- like "Unsupported marker type 0xC2", then you definitely have a progressive
- JPEG file and a non-progressive-capable decoder. (See part 2 of this FAQ
- for information about more up-to-date programs.) Or you may get a generic
- error message that claims the file is corrupted or isn't JPEG at all.
-
- Adobe Photoshop and some other prepress-oriented applications will produce
- four-channel CMYK JPEG files when asked to save a JPEG from CMYK image mode.
- Hardly anything that's not prepress-savvy will cope with CMYK JPEGs (or any
- other CMYK format for that matter). When making JPEGs for Web use, be sure
- to save from RGB or grayscale mode.
-
- Photoshop also has a habit of stuffing a rather large thumbnail/preview
- image into an application-private segment of JPEG files. Some other
- applications (notably early releases of Sun's Java library) are known to
- choke on this data. This is definitely a bug in those other applications,
- but the best available workaround is still to tell Photoshop not to save
- a thumbnail. If you're putting up an image on the Web, having a thumbnail
- embedded in it is just a waste of download time anyway.
-
- When transferring images between machines running different operating
- systems, be very careful to get a straight "binary" transfer --- any
- sort of text format conversion will corrupt a JPEG file. Actually that's
- true for all image formats not just JPEG.
-
- ------------------------------
-
- Subject: [17] How does JPEG work?
-
- Technical details are outside the scope of this FAQ, but you can find
- an introduction and references for further reading in the comp.compression
- FAQ, which is available from http://www.faqs.org/faqs/compression-faq/
- (see also "[24] Where are FAQ lists archived?").
-
- The comp.compression FAQ is also a good starting point for information on
- other state-of-the-art image compression methods, such as wavelets and
- fractals. A quick comparison: wavelets are likely to be the basis of the
- next generation of lossy image-compression standards, but they are perhaps
- 10 years behind JPEG in the standardization pipeline. Fractals have been
- terribly over-hyped by their chief commercial proponent, and seem to be
- losing favor as people learn more about their true capabilities and
- limitations.
-
- ------------------------------
-
- Subject: [18] What about arithmetic coding?
-
- The JPEG spec defines two different "back end" modules for the final output
- of compressed data: either Huffman coding or arithmetic coding is allowed.
- The choice has no impact on image quality, but arithmetic coding usually
- produces a smaller compressed file. On typical images, arithmetic coding
- produces a file 5 to 10 percent smaller than Huffman coding. (All the
- file-size numbers previously cited are for Huffman coding.)
-
- Unfortunately, the particular variant of arithmetic coding specified by the
- JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
- Thus *you cannot legally use JPEG arithmetic coding* unless you obtain
- licenses from these companies. (Patent law's "experimental use" exception
- allows people to test a patented method in the context of scientific
- research, but any commercial or routine personal use is infringement.)
-
- I recommend that people not use JPEG arithmetic coding; the space savings
- isn't great enough to justify the potential legal hassles. In particular,
- arithmetic coding *should not* be used for any images to be exchanged on
- the Internet. Even if you don't care about US patent law, other folks do.
-
- ------------------------------
-
- Subject: [19] Could an FPU speed up JPEG? How about a DSP chip?
-
- Since JPEG is so compute-intensive, many people suggest that using an
- FPU chip (a math coprocessor) should speed it up. This is not so.
- Most production-quality JPEG programs use only integer arithmetic and so
- they are unaffected by the presence or absence of floating-point hardware.
-
- It is possible to save a few math operations by doing the DCT step in
- floating point. On most PC-class machines, FP operations are enough slower
- than integer operations that the overall speed is still much worse with FP.
- Some high-priced workstations and supercomputers have fast enough FP
- hardware to make an FP DCT method be a win.
-
- DSP (digital signal processing) chips are ideally suited for fast repetitive
- integer arithmetic, so programming a DSP to do JPEG can yield significant
- speedups. DSPs are available as add-ons for some PCs and workstations;
- if you have such hardware, look for a JPEG program that can exploit it.
-
- ------------------------------
-
- Subject: [20] Isn't there an M-JPEG standard for motion pictures?
-
- As was stated in section 1, JPEG is only for still images. Nonetheless,
- you will frequently see references to "motion JPEG" or "M-JPEG" for video.
- *There is no such standard*. Various vendors have applied JPEG to
- individual frames of a video sequence, and have called the result "M-JPEG".
- Unfortunately, in the absence of any recognized standard, they've each done
- it differently. The resulting files are usually not compatible across
- different vendors.
-
- MPEG is the recognized standard for motion picture compression. It uses
- many of the same techniques as JPEG, but adds inter-frame compression to
- exploit the similarities that usually exist between successive frames.
- Because of this, MPEG typically compresses a video sequence by about a
- factor of three more than "M-JPEG" methods can for similar quality.
- The disadvantages of MPEG are (1) it requires far more computation to
- generate the compressed sequence (since detecting visual similarities is
- hard for a computer), and (2) it's difficult to edit an MPEG sequence on a
- frame-by-frame basis (since each frame is intimately tied to the ones around
- it). This latter problem has made "M-JPEG" methods rather popular for video
- editing products.
-
- It's a shame that there isn't a recognized M-JPEG standard. But there
- isn't, so if you buy a product identified as "M-JPEG", be aware that you
- are probably locking yourself into that one vendor.
-
- Recently, both Microsoft and Apple have started pushing (different :-()
- "standard" M-JPEG formats. It remains to be seen whether either of these
- efforts will have much impact on the current chaos. Both companies were
- spectacularly unsuccessful in getting anyone else to adopt their ideas about
- still-image JPEG file formats, so I wouldn't assume that anything good will
- happen this time either...
-
- See the MPEG FAQ for more information about MPEG.
-
- ------------------------------
-
- Subject: [21] What if I need more than 8-bit precision?
-
- Baseline JPEG stores images with 8 bits per color sample, in other words
- 24 bits per pixel for RGB images, 8 bits/pixel for grayscale, 32 bits/pixel
- for CMYK, etc. There is an extension that stores 12 bits/sample for
- applications that need higher accuracy. Medical images, for example, are
- often 12-bit grayscale. The 12-bit extension is not very widely supported,
- however. One package that does support it is the free IJG source code (see
- part 2, item 15).
-
- For lossless JPEG, the standard permits any data precision between 2 and 16
- bits per sample, but high-precision lossless JPEG is even less widely
- supported than high-precision lossy JPEG. The Stanford PVRG codec (see
- part 2, item 15) reportedly supports up to 16 bits/sample for lossless JPEG.
-
- ------------------------------
-
- Subject: [22] How can my program extract image dimensions from a JPEG file?
-
- The header of a JPEG file consists of a series of blocks, called "markers".
- The image height and width are stored in a marker of type SOFn (Start Of
- Frame, type N). To find the SOFn you must skip over the preceding markers;
- you don't have to know what's in the other types of markers, just use their
- length words to skip over them. The minimum logic needed is perhaps a page
- of C code. (Some people have recommended just searching for the byte pair
- representing SOFn, without paying attention to the marker block structure.
- This is unsafe because a prior marker might contain the SOFn pattern, either
- by chance or because it contains a JPEG-compressed thumbnail image. If you
- don't follow the marker structure you will retrieve the thumbnail's size
- instead of the main image size.) A profusely commented example in C can be
- found in rdjpgcom.c in the IJG distribution (see part 2, item 15). Perl
- code can be found in wwwis, from http://www.tardis.ed.ac.uk/~ark/wwwis/.
-
- ------------------------------
-
- Subject: [23] Where can I learn about using images on the World Wide Web?
-
- If you want to display still images on the World Wide Web, you have a choice
- of using JPEG or GIF; those two formats are by far the most widely supported
- by WWW browsers. (We can hope that PNG will soon become popular enough to
- replace GIF on the Web; see http://www.cdrom.com/pub/png/ for PNG info.)
- For most images it's pretty obvious which format to choose
- (see "[3] When should I use JPEG, and when should I stick with GIF?").
- JPEG's ability to trade off file size against image quality is especially
- helpful for trimming download times of Web photos.
-
- But there's a good many things to know that are specific to Web design,
- and even specific to the currently-most-popular browsers. This FAQ doesn't
- try to cover Web graphics design. Good basic information can be found at:
- http://www.boutell.com/faq/
- http://www.servtech.com/public/dougg/graphics/index.html
- http://www.webreference.com/dev/graphics/
- http://www.adobe.com/studio/tipstechniques/GIFJPGchart/main.html
- http://ppewww.ph.gla.ac.uk/~flavell/www/palette.html
- http://the-light.com/netcol.html
- and here are some sites with more advanced info:
- http://www.inforamp.net/~poynton/Poynton-colour.html
- http://www.photo.net/philg/how-to-scan-photos.html
- http://www.scantips.com/
-
- ------------------------------
-
- Subject: [24] Where are FAQ lists archived?
-
- Many FAQs are crossposted to news.answers. Well-run netnews sites will have
- the latest versions available in that newsgroup. However, there are a *lot*
- of postings in news.answers, and they can be hard to sort through.
-
- The latest versions of news.answers postings are archived at rtfm.mit.edu.
- You can retrieve this FAQ by FTP as rtfm.mit.edu:/pub/faqs/jpeg-faq/part1
- and rtfm.mit.edu:/pub/faqs/jpeg-faq/part2. If you have no FTP access,
- send e-mail to mail-server@rtfm.mit.edu containing the lines
- send faqs/jpeg-faq/part1
- send faqs/jpeg-faq/part2
- (If you don't get a reply, the server may be misreading your return address;
- add a line such as "path myname@mysite" to specify your correct e-mail
- address to reply to.) For more info about the FAQ archive, retrieve the
- file rtfm.mit.edu:/pub/faqs/news-answers/introduction.
-
- The same FAQs are also available from several places on the World Wide Web,
- of which my favorite is http://www.faqs.org/faqs/.
- This FAQ is http://www.faqs.org/faqs/jpeg-faq/.
- Other popular WWW FAQ archives include http://www.cs.ruu.nl/cgi-bin/faqwais
- and http://www.lib.ox.ac.uk/internet/news/.
-
- --
- tom lane
- organizer, Independent JPEG Group
- tgl@netcom.com or tgl@sss.pgh.pa.us
-