CompuServe Messages

GIF viewing problems

    05-Aug-91 17:53:40
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]