AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

1997.05.23 20:03 "PackBits confusion", by Richard J Kinch
1997.05.30 18:29 "Re: PackBits confusion", by Sam Leffler
1997.05.30 19:14 "Re: PackBits confusion", by Richard J Kinch
1997.05.30 22:02 "Re: PackBits confusion", by Helge Blischke

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