GIF viewing problems
05-Aug-91 17:53:40
Sb: #10920-GIF viewing problems
Fm: Steve Bennett/SYSOP 76702,1071
To: Syndesis 76004,1763
LZW (actually, this is a varient on LZ which is similar but not quite the
same as LZW, and actually slightly predates LZW… It's what the COMPRESS
program under UNIX was based upon. I read an excellent article on the 12
or so varient compression schemes based on LZ, of which LZW is only *one*,
despite which everyone tends to label the whole group as LZW… 🙂 as used
in GIF is probably the most efficient means of packing bitmaps where the
number of bits per pixel is 8 or less, and you want 100% accurate
reproduction. Since the varient used starts with a code size of <bits per
pixel> + 1, you aren't compressing any filler bits, and have a relatively
larger number of codes to work with.
Admittedly, the maximum size of 12 bits per pixel is a limit. It should
really have been 16, but 8 bit machines don't really have enough memory for
the code table in that case (needs a table 128K bytes in length, plus
another of 64K bytes in length to decompress…) and possibly more
importantly for the GIF designers, it would have been more difficult to
implement on an IBM PC due to the 64K segmentation.
While JPEG does a better overall job of compression, it does so by LOSING
data. A reconstructed JPEG compressed image is only an approximation of
the original image. At resolutions of over 72dpi, it becomes relatively
unnoticable as far as the differences are concerned (except *really* sharp
lines will blur…) unless you look closely. As such, it's useful for
photographic quality images of high resolution, but it's pretty useless for
CAD/CAM drawings, and lower resolution images.
The original LZW scheme is indeed not a very effective bitmap image
compressor (although it's still on average about as effective as Huffman
encoding, which is the only real alternative to the LZ schemes) since it
uses a fixed size 12 bit code, which means that most of the codes generated
actually pad out the data with pad bits. Or if you pack the bits together
(as, for example, ILBM does) into a byte, you don't get much of the
advantage of duplicate patterns of bits (which is how the LZ encoding
works) unless
[Continued in reply]