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):

'Tis a bit fuzzy, but still perceptable.

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

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