2017.07.11 06:03 "[Tiff] LZW read errors in recent TIFF releases", by Larry Gritz

2017.07.11 17:51 "Re: [Tiff] LZW read errors in recent TIFF releases", by Larry Gritz

Thanks so much for quickly diagnosing!

Sounds good. It had not cropped up as a real-world problem, only got spotted because my software has a testsuite that tries reading every image from the libtiff sample images. I'll just disable that one test for now, until the next libtiff release.

> On Jul 11, 2017, at 2:21 AM, Even Rouault <even.rouault@spatialys.com> wrote:

Has anybody noticed that with the last minor release or two, when reading the libtiff example image quad-lzw.tif, there are read errors like this:

Not enough data at scanline 0 (short 1536 bytes)

It's not just my software -- trying to 'tiffcp' the file results in:

LZWPreDecode: Warning, Old-style LZW codes, convert file.
LZWDecodeCompat: Warning, LZWDecode: Strip 0 not terminated with EOI code.
LZWDecodeCompat: Not enough data at scanline 0 (short 7680 bytes).
libtiffpic/quad-lzw.tif: Error, can't read strip 0.

It's on MacOS that I noticed this. Haven't tested other platforms yet.

Does this ring any bells? Anybody have any insight?

OK, after investigation I've identified this as a 4.0.8 regression regarding old-style LZW decompression. I've just fixed it in CVS with the following patch (that should apply on top of 4.0.8)

$ cvs diff -u -r1.55 -r1.56 libtiff/tif_lzw.c
Index: libtiff/tif_lzw.c
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_lzw.c,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56

--- libtiff/tif_lzw.c   17 May 2017 09:38:58 -0000      1.55
+++ libtiff/tif_lzw.c   11 Jul 2017 08:55:07 -0000      1.56

@@ -1,4 +1,4 @@

-/* $Id: tif_lzw.c,v 1.55 2017-05-17 09:38:58 erouault Exp $ */
+/* $Id: tif_lzw.c,v 1.56 2017-07-11 08:55:07 erouault Exp $ */

  * Copyright (c) 1988-1997 Sam Leffler
@@ -655,6 +655,9 @@

        bp = (unsigned char *)tif->tif_rawcp;
+ sp->dec_bitsleft = (((uint64)tif->tif_rawcc) << 3);
        nbits = sp->lzw_nbits;
        nextdata = sp->lzw_nextdata;
        nextbits = sp->lzw_nextbits;
@@ -764,6 +767,7 @@

+       tif->tif_rawcc -= (tmsize_t)( (uint8*) bp - tif->tif_rawcp );
        tif->tif_rawcp = (uint8*) bp;

        sp->lzw_nbits = (unsigned short)nbits;
        sp->lzw_nextdata = nextdata;

I've added a test case for this.

But also, thinking that maybe I have a wildly old example file ("old-style", as it said),

Yes, specific to that case. Regular LZW decompression works OK.

I tried to re-download the collection of example images from

> > ftp://download.osgeo.org/libtiff/pics-3.8.0.tar.gz <ftp://download.osgeo.org/libtiff/pics-3.8.0.tar.gz>

But the link fails. Maybe during the recent web site fiasco, this got lost in the shuffle?

The links works for me. Perhaps a temporary server overload?

Otherwsie there's also access through http:

> http://download.osgeo.org/libtiff/pics-3.8.0.tar.gz <http://download.osgeo.org/libtiff/pics-3.8.0.tar.gz>

> http://www.spatialys.com <http://www.spatialys.com/>

Larry Gritz