Note: This file has moved to notablog.

[ The following discussion dates from 1996-97, the days when most personal computers had at most 256-color displays. A recent reader, Michael J. Micek, pointed out the following: GIF uses a palette indexed at most eight bits wide, so a GIF made from a 24 bit photo must first have had two-thirds of the information thrown out. In those days, reducing an image to a web-safe palette yourself (rather than relying on the user's browser to decode/reduce/dither a JPEG well) made a certain amount of sense. Nowadays (January 2003) with (I think) 16bpp displays being the norm, using GIFs (or even PNGs) for photographs -- even on the web -- is fairly absurd, and people know this, even if they don't know why. ] I think the attribution below is correct, but the quoting is getting a bit fuzzy: Roy Anderson wrote: >>> Insofar as the photographs are concerned, try saving them as JPEG with >>> a competent photo tool and reducing their quality to a lower but fully >>> acceptable level. You can save much RAM doing this. > Hayward Johnson wrote: >> Actually, GIFs are more efficient, size-wise, and more compliant >> web-wise. And: PaintShop Pro (way less pricey than a photo tool) >> handles photos pretty darn well. And then Roy Anderson writes: > Hayward, I assumed Robert was speaking of printed catalogs, not > online catalogs. JPEG is still--IMHO--a better tool than GIF for > maintaining photographic image fidelity for photographs targeted for > print. This is also true if one wishes to exhibit quality > photographic images on the web, regardless of how viewers might > react to the slow display times that might be involved. GIF is more > suitable for the web, particularly if icons, clip art, lower-quality > photographs, and fast download times are of major consideration. > > Assumptions are dangerous in this business, correct? :-) Maybe some hard facts will clear up some of the confusion? GIFs use run-length lossless compression, JPEGs use lossy compression. I'm going to keep it simple because a) I don't know *all* the details :-) and b) I'm sure most people reading this don't want to know all the details. Doubtless somebody here knows a lot more than I do about the topic and will want to leap in with corrections... As I said above, GIFS use run-length compression. The image is on your screen as a long series of numbers, each number representing the color values for a single pixel. Run-length compression searches for "runs" of the same value and replaces them with a code saying "Repeat this value X times". GIFs do this for each line, and then keep track of the lines done so far, and if the next line is identical, just replaces the entire line with a code saying "Use line Y here". This approach to compression makes GIFs "lossless", meaning all of the actual data is preserved, and it also makes them better for line art and the like, since art created in a drawing program is much more likely to have evenly colored areas that will compress more effectively than highly textured areas, like a photograph. JPEGs work by trying to reproduce the change in color from one part of the image to another. So instead of encoding a section of the image as, say: "dark red 5 times, medium red 10 times, light red 20 times" ...a JPEG will code it as a value of red starting this dark at one spot and then progressing in a curve to this light at another spot. Actually, to be more specific, JPEG compression looks at the image in 8x8 pixel blocks and encodes each block to represent the change in color across the block. JPEG compression is also skewed to worry more about things the human eye is good at seeing (like luminance, or how bright the color is) and less about things the human eye is not so good at seeing (like like chrominance, or exact color shading issues). In an odd sense, this amounts to trying to record _what it looks like_, rather than what the actual values are. JPEG compression is "lossy", which means that some of the actual data is lost in the compression method. Specifically, like I said above, it throws away data it doesn't think is as important. This is one reason why JPEG isn't as good for line art - line art isn't built the way JPEG is designed to think about images. By the way, if you *really* want to know how JPEGs work, everything you need is at: http://www.faqs.org/faqs/jpeg-faq/part1/preamble.html Information specifically about jpeg compression is at: http://www.faqs.org/faqs/compression-faq/part2/section-6.html Be warned, the second FAQ is fairly heavy reading and will assume you know a lot about both imaging technology and programming.