LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
May 1997
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1997.05.30 18:29 "Re: PackBits confusion", by Sam Leffler
To: tiff@sgi.com
Subject: PackBits confusion
Date: Fri, 23 May 1997 16:03:25 EDT
From: "Richard J. Kinch" <kinch@holonet.net>
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