Xref: utzoo alt.graphics.pixutils:482 comp.graphics:14816 alt.sex.pictures.d:839 Path: utzoo!utgpu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!tut.cis.ohio-state.edu!pt.cs.cmu.edu!g.gp.cs.cmu.edu!tgl From: tgl@g.gp.cs.cmu.edu (Tom Lane) Newsgroups: alt.graphics.pixutils,comp.graphics,alt.sex.pictures.d Subject: JPEG update (Re: An interesting observation on image compression) Message-ID: <11305@pt.cs.cmu.edu> Date: 6 Dec 90 18:44:02 GMT References: <9098@scolex.sco.COM> Organization: Carnegie-Mellon University, CS/RI Lines: 70 In article <9098@scolex.sco.COM>, pavelr@sco.COM (Pavel Rozalski) describes a quick experiment with Greg Cockroft's "transform" program. Since "transform" is a crude implementation of the JPEG image compression standard that was discussed a few weeks ago, I thought it would be good to bring people up to date on that. I have formed a group of volunteers that intends to create a freely available implementation of JPEG image compression. Our initial effort will be to construct format conversion programs that convert between JPEG and existing popular image formats (GIF, for example). We expect that these programs will work on most Unix boxes, and we hope to create versions for DOS, Mac, and possibly Amiga machines as well. (We expect that images will be posted in JPEG format, then transformed into an existing format at the recipient's machine for viewing. Viewing programs that work directly with JPEG files may come along later, if the format becomes accepted by the net.) At present, we have hacked up a version of Cockroft's "transform" that implements true JPEG compression. It's still slow, inflexible, and unportable, but it is enough to let us experiment with the JPEG compression parameters. (There are something like 200 separate tunable parameters in the JPEG spec...) So far, it appears that large GIF images can be compressed by a factor of 5 or better with no visible change in image quality. (In the referenced article, Pavel Rozalski cites a factor of 8 for one test case; this seems high. It's also peculiar that his output GIF file is much smaller than his input; maybe his input file had 60K of garbage after the actual image??) I find that GIF files with 16 or fewer colors don't compress as well. Also, cartoon-type images with sharp boundaries between areas of uniform color expose the distortion introduced by JPEG compression much more than photographic images do. These kinds of images are already pretty small in GIF format, so it is likely that the net will continue to use existing formats for such images, even if JPEG is adopted as the customary format for large photographic images. In the referenced article, Pavel writes: > The gifs posted are probably taken from 24 bit scans > originally so there is already some data loss going from 24 bits down to > 8 bits, so the image 'purists' who are complaining that destructive > compresses are unacceptable have a largely moot point. Ideally we should > be distributing only 24 bit images but I doubt that the news sites > around the world would welcome a tripling of volume in certain high > volume groups. We are about to do some experiments with full-color source images. Based on experience so far, it seems likely that JPEG compression of 24-bit images will not be much larger than compression of 8-bit images (as the algorithm does not make use of the limited number of colors in 8-bit images). If this is true, converting to JPEG will make it possible to distribute 24-bit images for 5X less than the present cost of distributing 8-bit images. Those with less than 24-bit color display hardware will quantize colors when decompressing the JPEG file; I suspect it will be *extremely* difficult to distinguish the results of this process from an 8-bit image that has not been through JPEG. (This is not a claim that there will be no differences at the pixel level, but that it will be difficult to say which image is "better".) We could still use more volunteers for the implementation group, particularly people with experience in setting graphics standards and folk with experience in porting C programs to non-Unix machines. If you are interested please send e-mail to me. -- tom lane Internet: tgl@cs.cmu.edu UUCP: !cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu Brought to you by Super Global Mega Corp .com