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
Compression Scheme: LZW
Photometric Interpretation: min-is-black
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 Johnson <firstname.lastname@example.org>