1997.05.23 20:03 "PackBits confusion", by Richard J. Kinch

I have a number of PackBits-compressed images that seem to use the -128 opcode for a repetition code, which the TIFF 6.0 standard says is supposed to be a no-op. Loading these images with libtiff generates "PackBitsDecode: Not enough data for scanline" errors.

If I kludge PackBitsDecode() by removing the lines:

                        if (n == -128)  /* nop */
                                continue;

the images load correctly.

Is this a dangerous modification? What's the point of having a noop in the algorithm, anyway? Are there TIFF writers that use this? I can't see any purpose to it. Is it an lurking problem in the TIFF spec?

Most peculiarly, I have several independent, commercial TIFF-reading applications that accept such images (as well as several that don't).

Is is possible that the application that wrote these TIFF files is erroneously creating them with this opcode as a repetition count? That would be a nasty bug, especially since it is sometimes covered up by non-compliant readers.

Strangely, when I consulted my old 1988 TIFF 5.0 spec document from HP, I discovered that I had "corrected" the PackBits description to use -128 as a repetition code. I must have made that annotation while writing a TIFF reader some years ago. There was no annotation as to why I made the change.

Richard J. Kinch                         kinch@holonet.net
6994 Pebble Beach Court                  Publisher, TrueTeX (R) brand
Lake Worth FL 33467                          typesetting software.
Tel (561) 966-8400
FAX (561) 966-0962                       See http://idt.net/~kinch