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
Thread
2009.02.13 15:57 "Re: 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. Of course, this is not a small effort albeit simple. -Edward Philip Watkinson wrote: > Guys, > > 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. > > Regards, > Philip > > -----Original Message----- > 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 > > Bob, > >> 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. > > > Best regards, > > Joris > > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/