2008.02.18 23:28 "RE: [Tiff] TIFFRead errors on faxes", by Mick O'Neill

Fair enough Joris - thank you.

If the problem of reading past EOF has been handled in libtiff 4.0 (Note I am using Windows), then I certainly won't bother with the fix in 3.9. We really can't use 4.0 at the moment (the powers that be have kittens over using beta code in our production system - using alpha would give them a coronary), so I will simply do a simple test in the application code as I read the directories of the TIFF file initially - if a StripOffset + StripByteCount overlaps the starting byte of a directory, I will change the StripByteCount to (Directory Offset - StripOffset). Granted, this will probably read more data than is in the image, but as you said, excess image data will be thrown away. At least it will prevent the exception being thrown reading past EOF.

We do need to handle these files, as there are literally thousands of them out there - regardless of whether DataTech have fixed the problem or not (They may well have in FaxMan 4 - our software still uses 3.82, as they changed all the interfaces in 4.0, and we would need a total rewrite of our faxing module to upgrade).

Cheers all.

Mick.

-----Original Message-----
From: Joris Van Damme (AWare Systems)
[mailto:joris.at.lebbeke@skynet.be]
Sent: Monday, 18 February 2008 6:18 PM
To: Mick O'Neill; TIFF mailing list
Subject: Re: [Tiff] TIFFRead errors on faxes

Once again, I have some TIFF files that cannot be read. These TIFFs have come in through the Faxman faxing software, and when I try to

> read them through the 3.9.0 beta library, Page 2 reports a "Read error

> on line xxx: Expected bbb, got ccc" error. Brava Reader and Autovue

> can view these images ok.

Sample tiff files available from http://midimick.com/temp/fax1.tif and http://midimick.com/temp/fax2.tif

Whilst the problem in the TIFF files is meanwhile clear, the problem in LibTiff is not, to me. I've checked both files in LibTiff and I get a flawless rendering without warnings or errors. I use LibTiff 4.0, and I get the same results in both a test of low-level LibTiff (TIFFReadEncodedXxx) and RGBA interface. Seeing the nature of the problem, that result is as expected, remainder data after reading a strip or tile is ignored in most subcodecs in LibTiff, at most a warning is emited. You may want to post your exact calling code for us to be able to reproduce, and/or cross-test with LibTiff 4.0 and see if that results in the same problem on your end.

> Inside the

> library itself, it is easy to determine that this is occurring - if

> + StripByteCount overlaps another area of memory that the StripOffset

> mapped by another directory entry or its data, then it has > occurred. has been

Doing such memory-layout checking is not straightforward, nor recommended. Remember that a TIFF file has no predefined order of data blocks (for good reason). You may have many IFDs, many auxilliary tag data blocks, many strip/tile blocks, and they may be anywhere. Add to this that you may have unused space, either by first writing or as the result of later editing and re-appending of IFDs, and add to this that you may have private and unknown tags with datatype LONG that may or may not point to secondary IFDs.