2009.02.13 15:57 "Re: [Tiff] warning and errors", by Edward Lam

Personally, instead of an option to suppress certain warnings, I would rather see two enums created: one for errors, the other for warnings. These enums are then used to index into a string table.

eg.
TIFFWarningExt(tif->tif_clientdata, module,
            TIFF_WARN_UNKNOWN_FIELD,
            dp->tdir_tag, dp->tdir_tag);

where TIFF_WARN_UNKNOWN_FIELD indexes into a string table with the string literal "Unknown field with tag %d (0x%x) encountered".

There are two advantages to this method:

1. This allows the client to filter out specific errors/warnings without resorting to string matching.
2. It allows the possibility for localization of errors/warnings.
3. Of course, this is not a small effort albeit simple.

-Edward

Let me explain my situation. Our company provides automated document factory (ADF) solutions to many large financial institutions. For one client, they receive logos from their clients in TIFF files. There are thousands of files. When they run the application, they see warnings which scares them and they shut down thinking there is an error. The common warning is "unknown field with tag... ". If this warning has nothing to do with the core functionality of encoding and decoding images, it would be nice to have a switch to suppress these types of warnings.

From: Joris Van Damme (AWare Systems) [mailto:info@awaresystems.be] Sent: Friday, February 13, 2009 3:21 AM

To: Bob Friesenhahn; Philip Watkinson
Cc: Tiff List
Subject: Re: [Tiff] warning and errors

TIFF is a very flexible format. There are proprietary usages of TIFF which require special tags in order for the proprietary software to be able to read the file correctly. If a program using libtiff opens one of these files then the result may be gibberish. However, the user is likely to see a wrong looking image.

I humbly dissagree. TIFF only works if you separate the 'nominal' layer from the 'proprietary extension' layer. For example, say some app needs to store elevation data with a map encoded in normal RGB. What it should do is not apply some proprietary photometric RGBE, nor should it revert to a complete proprietary set of tags that totally excludes interchange. Instead, it should recognise that the 'nominal' and interchangeble way to communicate this is a normal TIFF with photometric RGB and four channels, the fourth channel being indicated as 'undefined'. Next, it might add an additional 'proprietary extension' adding a proprietary tag that fully defines the 'undefined' channel in a proprietary way. Unsuspecting software/users render/see the nominal RGB image. The specially aware software/user can make sense of the extra channel.

In short, 'extra' stuff should never obscure the 'standard' stuff, but fully and only build on from the latter. This way and only this way can an unknown tag and unknown channels always be safely ignored, and that is requirement for the extensibility of TIFF to actually work.