Xref: utzoo comp.graphics:15468 alt.graphics.pixutils:593 alt.sex.pictures.d:1376
Path: utzoo!utgpu!cs.utexas.edu!usc!julius.cs.uiuc.edu!rpi!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.graphics,alt.graphics.pixutils,alt.sex.pictures.d
Subject: Re: JPEG compression: "press release"
Message-ID: <2908@sixhub.UUCP>
Date: 21 Jan 91 04:09:18 GMT
References: <1984@umriscc.isc.umr.edu> <11623@pt.cs.cmu.edu>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Followup-To: comp.graphics
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 133


  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