2003.08.05 00:48 "[Tiff] Problem decompressing LZW Tiffs", by John Johnson

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?

John

John Johnson <john.johnson@keyholecorp.com>