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
July 2017

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

2017.07.11 06:03 "LZW read errors in recent TIFF releases", by Larry Gritz
2017.07.11 09:21 "Re: LZW read errors in recent TIFF releases", by Even Rouault
2017.07.11 17:51 "Re: LZW read errors in recent TIFF releases", by Larry Gritz

2017.07.11 17:51 "Re: 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:
> 
> Larry,
>  
> > 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;
> +#ifdef LZW_CHECKEOS
> +	sp->dec_bitsleft = (((uint64)tif->tif_rawcc) << 3);
> +#endif
>  	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>
>  
> Even
>  
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com <http://www.spatialys.com/>
--
Larry Gritz
lg@larrygritz.com