[WARNING: THE JPEGS IN THIS MESSAGE HAVE BEEN CONVERTED TO GIF. Click to download the originals]

Content-Type: application/x-nextmail
MIME-Version: 1.0 (NeXT Mail 3.3 v116.1)
From: Bill Bumgarner <bbum@friday.com>
Date: Wed,  8 Feb 95 22:53:31 -0600
To: Bruce Gingery <bgingery@Wyoming.COM>
Subject: Re: Your message of Wed, 8 Feb 95 20:18:34 -0700
cc: WebStep@mail.xent.caltech.edu
Reply-To: bbum@friday.com
X-A: I ride tandem with the random...
X-B: ...things don't run the way I plan them.

  # With the current Unisys/Compu$erve lock on .gif format, we are
  # going to see a LOT of variation in inlined images, of whatever
  # style, that use the LZW compression algorithm.
  # 
  # I'd suggest that the WebStep group allow the .gif and .xbm
  # which are currently in such widespread use, but promulgate jpg
  # compressed tiffs as a replacement standard.

The TIFF encapsulated JPEG "standard" is not terribly standard and is still up for some debate.

The Independent JPEG group provides excellent, highly portable jpeg compression/decompression tools (OmniImageFilter and PBMImageFilter use this library;  PBMImageFilter uses the UNIX executables - OIF uses the library). Basically every platform can read/write/image the JPEG group's file format.

The latest version can be found at:

ftp://ftp.uu.net/graphics/jpeg

> ... I, too, would like to move the WebStep community past
>  GIF, but that's not a practical vision for the Web as a
>  whole. Also, I doubt jpeg is the right answer for imaged
>  text (even in lossless mode).

    # I agree that raw jpg/jpeg are not, but the tiff spec has
    # plenty of room for specification of overlay text.

Interestingly, loss of quality isn't a problem with text -- it is more a problem of lack of compression.  I have enclosed some examples;  I hope no one is going to shoot more for bandwidth usage.

I took a small cutting from a terminal window containing the man page for cjpeg and compressed it using the shown commands.  The resulting sizes were:

-rw-r--r--   1 bbum     wheel      140630 Feb  8 22:40 text.ppm
-rw-r--r--   1 bbum     wheel        7616 Feb  8 22:39 text.tiff
-rw-r--r--   1 bbum     wheel        9961 Feb  8 22:40 text_25.jpeg
-rw-r--r--   1 bbum     wheel       18689 Feb  8 22:40 text_default.jpeg

This is the result text_default.jpeg (you will either need to convert this by hand or have OmniImageFilter/PBMFilter installed):

22 126.000000 372.000000 0  A 10 A 20 A B 52 /khare/Library/eText/BBumTiff.etfd/text_default.jpeg 17 text_default.jpeg¬

'Tis a bit fuzzy, but still perceptable.

With a pure black and white image, it looks nearly identical to the original:

22 131.000000 349.000000 0  A 10 A 20 A B 55 /khare/Library/eText/BBumTiff.etfd/bw_text_default.jpeg 20 bw_text_default.jpeg¬

but the compression ratios are even more depressing:

-rw-r--r--   1 bbum     wheel      137171 Feb  8 22:44 bw_text.ppm
-rw-r--r--   1 bbum     wheel        4676 Feb  8 22:43 bw_text.tiff
-rw-r--r--   1 bbum     wheel       10153 Feb  8 22:44 bw_text_25.jpeg
-rw-r--r--   1 bbum     wheel       18263 Feb  8 22:44 bw_text_default.jpeg

-----

I haven't had a chance to play with wavelet compression, but it allows for progressive refinement;  the longer you wait, the clearer the picture (it is a natural result of the algorithm, so there need not be any added tricks).

Fractal compression looks promising, but I have yet to find any encoders/decoders that are commonly available.

Of course, for either of these algorithms to be acceptable in an inherently cross-platform environment such as the web, they will have to undergo considerable evolution.

-----

For text and such, it seems that lempel-ziv is currently the best solution.  Are there any commonly understood, non-patent-abused formats that encapsulate lzw compression available?

[wouldn't it be great to simply have gzip available as filter for any data on the system -- just point it at the contents of an image and -- allakazam -- you have a gzip --best compressed image;  or some other, superior algorithm]

b.bum