AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

2009.09.07 17:02 "[Tiff] [Fwd: LZW-related bug in tif_read.c and/or bug in various LZW encoders]", by Andreas Kleinert

 -------- Original-Nachricht --------

 Betreff: LZW-related bug in tif_read.c and/or bug in various LZW encoders
 Datum: Mon, 01 Jun 2009 12:48:30 +0200
 Von: Andreas Kleinert <Andreas_Kleinert@gmx.de>
 An: tiff@lists.maptools.org

Dear all,

I'm using libtiff 3.9.0 and came across the following issue.

 After extracting the TIFF previews from a number of EPS files from
 different sources I get standalone TIFF files with LZW-encoded image data.

 Having these in a windows folder or using a typical image viewer
 like IrfanView they display fine and without any error.

 If I start using libtiff to decode them, I get the following
 kind of error:

         D:\eps_0.tif: Read error at scanline 4294967295;
         got 2577 bytes, expected 2578

(Let's ignore that the scanline information obviously is garbage.)

It seems there are LZW encoders which put one byte less than expected.

After tracking the source of the error down to tif_read.c line 195

 ***
                 cc = TIFFReadFile(tif, buf, size);
                 if (cc != size) {
                         TIFFErrorExt(tif->tif_clientdata, module,
                 "%s: Read error at scanline %lu; got %lu bytes, expected %lu",
                             tif->tif_name,
                             (unsigned long) tif->tif_row,
                             (unsigned long) cc,
                             (unsigned long) size);
                         return (-1);
                 }
 ***

I've changed the last line as follows:

if(abs(cc-size)>1) return (-1); // FIX! AKL

This fixes the issue. All the files start working.

My question/suggestion is as follows:

 - is this a known issue?
 - has it been introduced between v3.6.x and v3.9.0?
   (I think so, as I remember by code having worked earlier...)
 - does anyone know the real reason behind it, i.e.
   are there LZW files being written with missing end-/fill-byte?
 - is the patch (as described before) acceptable for everyone?
 - if not, would it be acceptable if the condition would also check for
   the filetype (LZW)?
 - is there a better place to fix this?
 - who will fix? :-)

If anyone wants sample files (EPS or extracted TIFF) I may provide them.

BR,
Andreas

 --
 Dipl.-Ing. Andreas Kleinert VDI (Andreas_Kleinert@ieee.org)
 Embedded Systems Software Consultant

PGP Key: http://pgp.mit.edu/ -- Search: "Andreas Kleinert"