Xref: utzoo comp.graphics:15474 alt.graphics.pixutils:596 alt.sex.pictures.d:1395 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!g.gp.cs.cmu.edu!tgl From: tgl@g.gp.cs.cmu.edu (Tom Lane) Newsgroups: comp.graphics,alt.graphics.pixutils,alt.sex.pictures.d Subject: Re: JPEG compression: "press release" Message-ID: <11633@pt.cs.cmu.edu> Date: 21 Jan 91 20:55:03 GMT References: <1984@umriscc.isc.umr.edu> <11623@pt.cs.cmu.edu> <2908@sixhub.UUCP> Followup-To: alt.graphics.pixutils Organization: Carnegie-Mellon University, CS/RI Lines: 164 (I shoulda put a Followup-To: on the original article. Please direct any further followups to alt.graphics.pixutils.) In article <2908@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > [a bunch of questions and complaints about JPEG performance] Bill has raised some good points that I didn't cover adequately in my original article. I'll try to reply to these. To begin with, I should remind everyone that the JPEG group has no power to impose anything on anybody. If the net finds what we do to be useful, it'll get used. If not, not. People who don't find JPEG to be appropriate for a particular application can always do something else. > | It is true that JPEG is inherently a "lossy" format; the output is > | generally not pixel-for-pixel the same as the input. > > The question (of opinion) is if the average image can stand the loss. > To say that the photo is not the image, and the 24 bit scan is not the > photo, and the GIF is not the 24 bit scan is all true, I question if all > the losses inherent in the process justify a technique which introduces > more, or rather justifies any effort not to lose more data than is > already gone. Certainly there are applications where exact pixel-for-pixel reproduction is essential, and for these applications JPEG is inappropriate. I submit, however, that "recreational" images such as are usually transmitted around the net do not fall into this category. I believe that most net users would gladly trade off barely-visible defects for an increase in the net's ability and willingness to support posting of images. I find it interesting that Bill makes no comment on whether he looked at my sample images, and if so what he thought of them. I thought of posting several alternatives "blind" (not labelled) and challenging people to rank them quality-wise. The results of such a survey might be relevant to this debate. > | A number of people have tested JPEG on the basis of GIF->JPEG->GIF > | conversions. This isn't really a fair comparison since JPEG is actually a > | 24-bit-color format. If you start with a GIF image you have already > | introduced color quantization artifacts by reducing the original scene to > | 256 or fewer colors. This process creates high-frequency color "noise" > | (particularly if color dithering is used), which JPEG isn't designed to > | reproduce real well. You get considerably better results if you do the > | color quantization only after decompressing the JPEG image. > > Would it be fair to say that the losses are so severe that you must > start with a 24 bit image in order to get an acceptable eight bit image? No, it would not. Most of the testing I've done has been with 8-bit GIFs as source images (I haven't the disk space to spare for 24-bit images). I find JPEG-processed versions to be quite acceptable. What I meant was that pixel-for-pixel reproduction of a color-dithered GIF image is a *more difficult* task for JPEG than pixel-for-pixel reproduction of a 24-bit image. Color dithering exploits the eye's lack of sensitivity to high-frequency color information, which is exactly the same information that JPEG throws away. (For those who are wondering what color dithering is: suppose you have an area of an image that doesn't match any of the colors available in your limited 256-color GIF colormap. If you pick the closest available color and set all the pixels to that color, you retain spatial resolution but lose color fidelity. The idea behind dithering is to take small groups of pixels, say 2x2 blocks, and color the pixels within a group differently, so that the *average* over the group is the desired color. As long as you don't look too closely, the eye averages out the different-colored pixels. You get better color fidelity at the price of giving up some resolution. The differences between adjacent pixels in a dithered image amount to a high-frequency color signal, which is exactly what JPEG "knows" it can throw away. To some extent, JPEG will do the same averaging that the eye does; so the compressed image is actually not a bad representation of the original scene, although it cannot regain the resolution lost to dithering. But when the image is decompressed and redithered, it's almost certainly not going to be pixel-for-pixel the same as the input image, if only because of differences in dithering algorithms --- there are lots of different ways to dither. Note that you are still going to have to look closely to notice the differences.) > I have the feeling that there are a lot more images created with an > eight rather than 24 bit scanner, and that unless the noise generated by > having the scanner do the reduction to 256 colors is handled better than > the noise of having GIF conversion do it, then I question if JPEG is > useful for anything which is eight bit data, however reduced. Yes, > that's a question, not a statement of opinion. I'm not very familiar with 8-bit scanners; do they have built-in color dithering? If so, a JPEG processor would have some difficulty in exactly reproducing the scanner's output. The exact results would depend largely on the details of the scanner's dithering algorithm and on how this interacts with the dithering that the JPEG decompressor uses to produce a colormapped output file. However, this still only means that the result is *different*; whether it is better or worse, and how closely you have to look to decide, is an experimental question. > Also, is there any 24 bit viewing hardware readily available for > machines such as the Mac, PC, or Amiga? I'm aware of expensive Mac stuff and more reasonably priced Amiga stuff. In any case, I made no claim that 24-bit color was a serious concern now, only that it would be in a few years. > | It's worth pointing out that the JPEG standard has an *enormous* parameter > | space (about 200 distinct 8-bit values)... > > The question arises if the parameters will have to be tuned on a "per > image" basis to give satisfactory results. While this is possible, it > certainly requires serious development of an algorithm better than "try > it and see how it looks," or reversing the compression and testing the > reconstituted image against the original to minimize damage. This is an interesting research problem (anybody out there need a thesis topic?) but it doesn't seem to me to be an immediate objection. For the moment I think that most people will be satisfied with choosing one of two or three "standard" parameter sets, depending on how picky they are and on how good the original image is. I might point out, incidentally, that I can think of quite a lot of cases where a very compressed, not-very-high-quality image is exactly what is wanted (for instance, an inessential illustration within a netnews article, or in a catalog of an image database). JPEG's ability to support both low and high quality strikes me as a strength, not a weakness. > At this point I'm unsure of the place of JPEG. I personally find that > I'm marginally satisfied with the detail I can get from a 600 dpi 24 bit > scan, when compared to the original. While some of the images posted > could certainly stand to lose some (or all) detail, I'm not sure there's > enough information to make part of it acceptable. > > I hope that the people who are working with JPEG will continue > sharing their results with us, but I wish that no effort would be made > to convince people that it is the one true solution until the results > are in from some of the people who have begin working on better > compressors which preserve all data. Far be it from me to claim that JPEG is the last word on image compression. However, we have a problem *now*, and waiting for hypothetical future research results does not seem like a reasonable solution. Those who find 600 dpi 24 bit color to be the minimum acceptable resolution are welcome to create and view such images in the privacy of their own homes. I doubt that the net will stand for shipping around large numbers of images of that size, especially not for purely recreational purposes. My personal objective is to make decent-quality images small enough so that the net can afford to support recreational usage. > ... I think transmission with full detail is desirable, > allowing the people who need to use a compression like JPEG to save > space to make that compromise themselves. The point is that we are concerned about saving transmission bandwidth (and netnews spool storage, which is essentially the same thing). What people do for long-term storage on their own disks is their own affair, but what they post on Usenet is everyone's burden. -- tom lane Internet: tgl@cs.cmu.edu UUCP: !cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu