This is TXT.rtf in view mode; [Download] [Up]
[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):
'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
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.