Jpeg Press Release

Rob Harper harper at
Wed Dec 11 06:17:32 EST 1991

Archive-name: graphics/pixutils/jpeg/1991-01-20

Mike Castle (mcastle at 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 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 (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

More information about the Bio-soft mailing list