1997.05.30 18:29 "Re: PackBits confusion", by Sam Leffler

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?

Noops can potentially be useful if you need to pad data to a specific boundary; e.g. to a cacheline or page boundary. The TIFF spec for this compression algorithm explicitly defines -128 as a noop--changing it for your purpose means you may not be able to correctly decode other correctly encoded images. I'd consider your image data to be invalid. Of course that's not going to help you, but given that you have the source code you can wack it any way that you want.

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.

Sure. Since there's never been a TIFF "validation suite" (other than possibly my software) many vendors have implemented incompatible versions of the TIFF spec. There are several oddities throughout the TIFF spec that make no sense but are nonetheless de facto standard by now--for example the fact that the LZW encoding algorithm is suboptimal in its use of codes. My understanding was that PackBits was spec'd to be compatible with the Mac ROM implementation. I know nothing about Macintosh/Apple systems so don't know if -128 is a noop or a repetition code.

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.

HP has been known to generate "unique" TIFF images; I wouldn't consider documentation from them as a spec.

If you can demonstrate to me that this problem is widespread then perhaps we can add a flag to the library to control the handling of a -128 code and then add an option to tiffcp to use in converting files to a valid format. Freel free to send me changes along this line...

        Sam