tgl@g.gp.cs.cmu.edu (Tom Lane) (03/08/91)
In article <45216@ut-emx.uucp>, readdm@ccwf.cc.utexas.edu (David M. Read) writes: > You can contact the JPEG group by mailing to jpeg@think.com, or (I may > be wrong on this one! It's been a while!) ortiz@think.com. Please, please, no, ... we don't need requests to join sent to the whole group! If you want to join, send a request to jpeg-request@think.com. Attached is a "press release" posting I made a while back. Subject: JPEG compression: "press release" Date: 20 Jan 91 22:38:19 GMT 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