[alt.graphics.pixutils] JPEG update

fisher@afaf-vax.edwards.af.mil (12/06/90)

In article <11305@pt.cs.cmu.edu>, tgl@g.gp.cs.cmu.edu (Tom Lane) writes:
> 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.
> 
Are you looking for people to test it under VAX/VMS?

Lawrence Fisher
FISHER@EDWARDS-VAX.AF.MIL

tgl@g.gp.cs.cmu.edu (Tom Lane) (12/07/90)

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: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl
BITNET: tgl%cs.cmu.edu@cmuccvma
CompuServe: >internet:tgl@cs.cmu.edu