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 2009

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

2009.02.12 21:10 "warning and errors", by Philip Watkinson
2009.02.12 22:53 "Re: warning and errors", by Frank Warmerdam
2009.02.12 23:06 "Re: warning and errors", by Philip Watkinson
2009.02.12 23:56 "Re: warning and errors", by Bob Friesenhahn
2009.02.13 00:07 "Re: warning and errors", by Frank Warmerdam
2009.02.13 08:21 "Re: warning and errors", by Joris Van Damme
2009.02.13 15:15 "Re: warning and errors", by Philip Watkinson
2009.02.13 15:57 "Re: warning and errors", by Edward Lam
2009.02.13 18:28 "Re: warning and errors", by Bob Friesenhahn
2009.02.13 17:27 "Re: warning and errors", by Bob Friesenhahn
2009.02.13 08:34 "Re: warning and errors", by Joris Van Damme

2009.02.13 08:34 "Re: warning and errors", by Joris Van Damme

Philip,

> We want to use Libtiff in a production evironment. We don't want
> warnings/error messages unless there is a critical error (the image is
> corrupt).

What means 'critical'?

In my own proprietary codec, I separate error logic that applies to the 
system level, the IFD level, any particular tag, the image interpretation, 
and the image rendering. For example, corrupt JPEG data in one tile/strip, 
is not even visible on the IFD level, applications can still 
link/unlink/browse through the IFD list. It doesn't apply to the tag level 
either, and the image interpretation is still possible. However, it does 
'critically' impact part of the image, and in my codec it translates to that 
part being rendered in a consistent 'error color'. A totally different 
situation arises when an IFD has an EXIF tag whose value points beyond EOF. 
IFD reading and handling of the IFD that contains the EXIF tag is fine, so 
is image interpretation and image rendering. Tag reading on the EXIF tag is 
what logically contains the error. A totally different situation arises when 
the system is short of memory at some point.

I've found that the only way to always fully 'contain' the error and recover 
on the correct level, fully exposing all possible functionality that is not 
impacted, is a bit of a brainteaser and can only safely be provided by a 
TIFF codec that separates all different structures involved and consistently 
links errors to the exact structure they apply to. In LibTiff, you've no 
such functionality and you must choose to either minimize recovery, doing 
things like immediatelly backing out of the complete file whenever anything 
goes wrong, or minimize safety, doing things like continuing processing on 
other IFDs when the error returned might actually indicate system-wide 
failure like memory shortage.


Best regards,

Joris