AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
February 2008

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2008.02.18 00:40 "TIFFRead errors on faxes", by Mick O'Neill
2008.02.18 01:06 "Re: TIFFRead errors on faxes", by Bob Friesenhahn
2008.02.18 03:15 "Re: TIFFRead errors on faxes", by Frank Warmerdam
2008.02.18 06:40 "Re: TIFFRead errors on faxes", by Mick O'Neill
2008.02.18 07:41 "Re: TIFFRead errors on faxes", by Rob Van Den Tillaart
2008.02.18 08:17 "Re: TIFFRead errors on faxes", by Joris Van Damme
2008.02.18 23:28 "Re: TIFFRead errors on faxes", by Mick O'Neill

2008.02.18 08:17 "Re: TIFFRead errors on faxes", by Joris Van Damme

Mick,

Mick O'Neill wrote:
> 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 the
> StripOffset + StripByteCount overlaps another area of memory that has
> been mapped by another directory entry or its data, then it has
> occurred.

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.


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html