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 08:21 "Re: warning and errors", by Joris Van Damme
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