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 <firstname.lastname@example.org> 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
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/>