2000.11.15 19:19 "Has something changed with error detection in group4 data?", by Randall Myers

2000.11.16 11:02 "Re: Has something changed with error detection in group4 data?", by Joris Van Damme

the worst case (no errors detected when they clearly exist)

Is this the worst case? In my use of LibTiff, I'm confronted with a very related though opposite problem. It seems the library can go on and produce a reasonable image sometimes even after an error has been omitted. This, from my point of view, is a bug. An error should envoke the LibTiff encapsulator to give up on the image (mine does). If not, chances are that even bigger problems (in the order of crashes and non-predictable behaviour) might occur. Therefore, in my opinion, if the library can go on decoding the image, a warning should be emitted instead of an error. That is the key difference between a warning and an error, actually, in my humble opinion.

And no, the result code from the LibTiff functions are not a reliable way to see if the library can go on or not. I've found them to be totally unreliable. If I listen to these, many images are returned that are just plain empty and useless, and clearly should have been treated as fatally unreadable.

Indeed, I've got the impression that this faulty warning/error behaviour is a big issue espessially in the g3/g4 fax decoders. Perhaps it ought to be cleaned that up, and rendered predictable, reliable and systematic.

In the past I have been able to correlate the behavior (with regard to corrupt images) of "tiffinfo -D" and that of the readers which our customers use (Microsoft Imaging).

Indeed, it would be nice if there were a correlation. After all, the warning/error behaviour should tell the user more about the acutal image file than about the actual image reader. At least, that's my opinion.