| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2003.08.05 00:48 "Problem decompressing LZW Tiffs", by John JohnsonI 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> |
|||||||