tgl@g.gp.cs.cmu.edu (Tom Lane) (01/21/91)
Mike Castle (mcastle@mcs213f.cs.umr.edu) writes: > Maybe Tom should post an "official press-release" on how the project is > coming along. Something a little more detailed than his last, anyway :-> OK, here is a "press release" about the free JPEG effort. I have also included some responses to questions and complaints about JPEG in general. 1. What is the free JPEG group doing? Our goal is to produce a freely available, high-quality implementation of the JPEG image compression standard. "Free" means just that: we will give away source code, and you can use it for whatever purpose you like. (We have not quite decided whether to put X-Windows-style copyrights on the code or to make it straight public-domain, but in any case it will be free for both commercial and noncommercial use. We will *not* put GNU-like restrictions on it.) Our immediate plan is to create only format-conversion software: programs to convert images between JPEG-compressed format and other popular formats such as GIF, TIFF, PPM, etc. To view a JPEG image you'll need to convert it into whatever format you use now and then use an existing viewer program. If JPEG becomes widely accepted, we expect that other people will incorporate our code into viewers and so forth. One reason for not tackling viewers now is that it's very tough to build portable viewing software, and portability is an essential requirement for what we're doing. We intend to produce a generic Unix implementation, which will work with Jef Poskanzer's PBMPLUS package. We will also produce standalone programs that work on non-Unix machines; presently we have people committed to build MS-DOS, Macintosh, and Amiga versions of the software. (If your favorite machine isn't on this list, don't whine --- volunteer.) The standalone programs will probably not be able to read and write as many image formats as the full PBMPLUS package can handle, but they will be able to handle several popular formats. We hope to make our software sufficiently modular so that the guts of it can readily be incorporated into other programs. 2. Why are we doing this? Partly for fun (JPEG is a real technical challenge), but mostly as a service to the net. In particular, we can read the handwriting on the wall with respect to alt.sex.pictures: it is not going to last long unless its bandwidth usage is cut significantly. Widespread usage of JPEG for image posting will help a lot. We also hope that the availability of a compact image format will allow wider usage of pictures on the net. (See Dave Read's proposal for a general purpose rec.images newsgroup, which will come to a vote soon.) We recognize that the net is not going to adopt any new posting format unless free or very inexpensive software is available for a wide variety of machines. We hope that we can cover enough machines to let JPEG reach "critical mass" and become a de-facto standard on Usenet. Once that happens, people with unusual hardware can adapt our source code to run on their machines. Another reason for our work is to encourage compatibility. The draft JPEG standard is an extremely loose document: a large number of decisions are left up to the individual implementor. People working in isolation are likely to produce implementations that can't actually exchange JPEG-format files. (I hear that this has already happened with the first several commercial JPEG implementations for the Macintosh.) By making and giving away a high-quality implementation, we hope to establish a de-facto standard for JPEG file format and to provide a painless path for people to adhere to that particular interpretation of the JPEG standard. Incidentally, we are seeking to cooperate with commercial JPEG developers to ensure that a common format is established, even with people who don't want to use our code. If you are part of a company working on a JPEG project, *please* contact me so that we can keep in touch. 3. Who are these guys, anyway? I (Tom Lane) am just the instigator and organizer of the project. A number of fairly well-known computer graphics people have joined the group, including Jef Poskanzer (author of PBMPLUS) and Lee Crocker (Piclab). We have also got members from several commercial outfits including Pixar and Thinking Machines. (I think most of them are doing it on their own time, though.) 4. Isn't JPEG really slow? Well, it's not lightning-fast, but it's not that bad. The prototype implementation we have now, on my 25MHz 68030 Unix box, can decompress a typical 512x480 image in a little over one CPU minute (and a good fraction of this time is spent in the color quantization step, which is not needed if you convert to 24-bit-RGB formats). We have not paid much attention to performance optimization so far, so I'm confident that the final version will be faster. On typical PC-class hardware, a couple of minutes to decompress an image is probably a good ballpark estimate. Note that you do *not* have to pay this price every time you want to view an image; you can convert it once to some other format. We regard JPEG as a format for distribution and long-term storage of images, not for use with images that you are actively working on. For many people on the net, the savings of transmission time will more than make up for the conversion time. The 512x480 image I just checked is 168Kbytes in GIF format and 33Kbytes in JPEG format. Since I have to download posted images from my netnews server at 2400baud, it would take me about ten minutes less to download that image in JPEG format; I can convert it back to something displayable and still be eight or nine minutes ahead (not to mention the savings on my phone bill). 5. What about image quality? It is true that JPEG is inherently a "lossy" format; the output is generally not pixel-for-pixel the same as the input. However, with proper choices of the JPEG compression parameters, the differences will be extremely hard to detect with the naked eye. The standard is designed to take advantage of known limitations of the human eye and brain. Furthermore, the compression parameters can be adjusted to trade off compression ratio against image quality. I beg of you not to judge the JPEG standard solely by the recently posted Image Alchemy program. Image Alchemy is not a very good implementation of JPEG. For one thing, they do not do post-DCT smoothing of the output image, which we find to be essential for decent image quality. They also seem to have some outright bugs in color handling; in one test I ran, their output image "faded out" (lost color saturation) at *higher* values of their quality setting. This should not happen at any quality setting. 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. I have placed some companion postings in alt.sex.pictures (for lack of a better place) which show a fairer comparison. I started with a small section of a 24-bit-RGB image and converted it to JPEG and back, at two different quality/compression settings. I then converted both the original image and the two de-JPEGed images to GIF format for posting. (I would have posted the 24-bit images, but they're big and I get the impression that not many people on the net have 24-bit-RGB display hardware.) I believe these images give a fair comparison of JPEG's potential, assuming that (a) JPEG is used right off the bat for compressing images obtained from color scanners, and (b) the ultimate viewer has 8-bit-color display hardware, so that color quantization must be used at some point. Here are some stats about the sample images: Dimensions: 200x200 pixels Size in 24-bit-RGB format: 120000 bytes (3 bytes/pixel) Original image converted to GIF: 39162 bytes JPEG file at the higher quality: 9492 bytes (4x smaller than GIF) JPEG file at the lower quality: 5311 bytes (7x smaller than GIF) The particular compression parameter settings I've used are just examples; plenty of higher, lower, and in-between settings are possible. Incidentally, this was done with our prototype software, not with Image Alchemy. For equivalent compression parameter settings, I.A. produces a larger JPEG file and a poorer-quality output image than ours does. It's worth pointing out that the JPEG standard has an *enormous* parameter space (about 200 distinct 8-bit values), and there is no reason to think we've found the best parameter settings yet. Further experimentation may yield parameter values that give higher quality for the same compression ratio (or equivalently, more compression for the same quality). Since a JPEG file includes the parameter settings used to compress the file, older JPEG software will still be able to decompress images made with better parameter settings. 6. Why should the net convert to JPEG? Principally, to reduce bandwidth and storage requirements for posted images. JPEG images can be at least a factor of 4 smaller than GIF images with hardly any visible change in image quality; factors of 7 to 10 are achievable with not a lot of quality loss (the resulting images are still much better than many that I've seen posted). Secondly, because JPEG preserves full 24-bit-color image information at no extra cost. As more people get 24-bit-color display hardware, this will become an important consideration. 7. How soon will the free JPEG software be ready? We're not very far along yet. We have a quick-and-dirty prototype implementation, which is not very fast or portable. We intend to rewrite from scratch to produce the final version. We do not wish to release what we have now. At our present rate of progress, I would guess we will have releasable software sometime this spring. We could still use the help of some more folks; if you'd like to volunteer, contact me by e-mail. We'd prefer people who have internet FTP access. -- tom lane Internet: tgl@cs.cmu.edu UUCP: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/21/91)
Please do not interpret this as an attack on any of the people involved, or JPEG in general. I have been very unhappy with what I have seen so far, and do have some comments and questions. In article <11623@pt.cs.cmu.edu> tgl@g.gp.cs.cmu.edu (Tom Lane) writes: | 5. What about image quality? | | It is true that JPEG is inherently a "lossy" format; the output is | generally not pixel-for-pixel the same as the input. However, with proper | choices of the JPEG compression parameters, the differences will be | extremely hard to detect with the naked eye. The standard is designed to | take advantage of known limitations of the human eye and brain. | Furthermore, the compression parameters can be adjusted to trade off | compression ratio against image quality. 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. | I beg of you not to judge the JPEG standard solely by the recently posted | Image Alchemy program. Image Alchemy is not a very good implementation of | JPEG. For one thing, they do not do post-DCT smoothing of the output | image, which we find to be essential for decent image quality. They also | seem to have some outright bugs in color handling; in one test I ran, their | output image "faded out" (lost color saturation) at *higher* values of | their quality setting. This should not happen at any quality setting. I certainly agree that the Alchemy program is not useful for anything other than producing seriously muddy images. I created images of a woman (face only) at quality levels 10, 32, 50, and 99, all of which lost the individual strands of her hair blowing in the wind. Even a 320x200 GIF image preserved at least some of the hair, and far better texture. This was done from an eight level scan. I was also unable to get the program to produce a viewable image on any VGA or 8514, including real IBM hardware. The screen turns blue, stays in text mode, and that's it. | 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. 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. 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? Also, is there any 24 bit viewing hardware readily available for machines such as the Mac, PC, or Amiga? I am aware of some seriously pricy 24 bit display stuff for Mac, but it represents about half the cost of the machine, and is not likely to be in the budget of the average person, or even company unless they have an actual need. | It's worth pointing out that the JPEG standard has an *enormous* parameter | space (about 200 distinct 8-bit values), and there is no reason to think | we've found the best parameter settings yet. Further experimentation may | yield parameter values that give higher quality for the same compression | ratio (or equivalently, more compression for the same quality). Since a | JPEG file includes the parameter settings used to compress the file, older | JPEG software will still be able to decompress images made with better | parameter settings. 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. | 6. Why should the net convert to JPEG? | | Principally, to reduce bandwidth and storage requirements for posted | images. JPEG images can be at least a factor of 4 smaller than GIF images | with hardly any visible change in image quality; factors of 7 to 10 are | achievable with not a lot of quality loss (the resulting images are still | much better than many that I've seen posted). Unfortunately I don't believe that this will redsuce net bandwidth as much as you would believe. My feeling is that as long as there is any visible loss of resolution people will see something interesting in JPEG and then a posting in GIF format will appear. | Secondly, because JPEG preserves full 24-bit-color image information at no | extra cost. As more people get 24-bit-color display hardware, this will | become an important consideration. 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. All of your points about 24 bit in the future are well taken, and I agree. More color will come a lot sooner than more resolution, unfortunately. What you read as a need for JPEG I read as a need for a better way to compress high resolution 24 bit color images. I am not giving up hope for a better non-lossy method yet. 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. I think that for the person who must store lots of data with fidelity not too important, that JPEG is probably the method of choice (barring some huge breakthrough in other methods). Examples of this are photos of houses for real estate, people for identification, and other places where the overall effect is more important than the tiny details. For other images, 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. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
tgl@g.gp.cs.cmu.edu (Tom Lane) (01/22/91)
(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: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu