TIFF and LibTiff Mail List Archive


2003.08.05 00:48 "[Tiff] Problem decompressing LZW Tiffs", by John Johnson
2003.08.05 01:55 "[Tiff] Problem decompressing LZW Tiffs", by Frank Warmerdam
2003.08.05 08:58 "[Tiff] Problem decompressing LZW Tiffs", by Andrey Kiselev
2003.08.05 12:39 "[Tiff] Problem decompressing LZW Tiffs", by Tom Kacvinsky
2003.08.05 17:28 "[Tiff] Problem decompressing LZW Tiffs", by Andrey Kiselev

2003.08.05 01:55 "[Tiff] Problem decompressing LZW Tiffs", by Frank Warmerdam

I recently rev'd my version of libtiff to 3.6.0-beta2.

The reading of lzw compressed tiffs (generated by photoshop) broke with the update. The routines pretend to do the work but the resulting bits returned are substantially different from before. :-(

I was able to track the problem down to revision 1.17 of tif_lzw.c. That is the version where the call to TIFFPredictorInit was removed from TIFFInitLZW and deferred until LZWSetupDecode. Putting the call to TIFFPredictorInit back into TIFFInitLZW fixes the problem. I stepped through it in the debugger and the deferred call to TIFFPredictorInit does eventually happen but too late to do any good. The old way called PredictorSetupDecode and then later called LZWSetupDecode. The new method only calls LZWSetupDecode.

I'm not sure if this happens on all LZW compressed tiffs or not.

I'm using gdal to interface with libtiff.

I've got a tiff I that demonstrates the problem, but it's a bit large to send to the entire list (~6M). I can email or ftp it somewhere if needed. Here's

the output from tiffinfo:

TIFFReadDirectory: Warning, milwaukee-p1-latlon-mask.tif: unknown field with tag

 37724 (0x935c) encountered.

TIFF Directory at offset 0x8
    Subfile Type: (0 = 0x0)
    Image Width: 26026 Image Length: 13605
    Resolution: 72, 72 pixels/inch
    Bits/Sample: 8
    Compression Scheme: LZW
    Photometric Interpretation: min-is-black
    Samples/Pixel: 1
    Rows/Strip: 1
    Planar Configuration: single image plane

  Photoshop Data: <present>, 2268 bytes
  Predictor: horizontal differencing 2 (0x2)

Did deferring the call to TiffPredictorInit solve another bug? Or can it be safely rolled back?


Andrey is digging into this problem already. Andrey, what is the bug number in Bugzilla? I can't seem to find it. libtiff 3.6.0 final will not be released without this being fixed, in the meantime you might be wise to regress tif_lzw.c. My changelog entry for the offending "fix" reads:

         * libtiff/tif_lzw.c: fixed so that decoder state isn't allocated till
         LZWSetupDecode().  Needed to read LZW files in "r+" mode.

So, as long as you are opening the file only in read mode, and not "r+" mode you should be ok with the regressed version.

Best regards,

I set the clouds in motion - turn up   | Frank Warmerdam,
light and sound - activate the windows |
and watch the world go round - Rush    | Geospatial Programmer for Rent