LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2006
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
2006.09.25 17:27 "Re: Handling of EXIF IFD in Libtiff", by Joris Van Damme
Phil, > (I don't expect a response to this -- I'm just venting because this > touches on some aspects of the TIFF specification which I find very > unfortunate.) I'm not very good at not responding. ;-) > > a) goes against the TIFF spec that says tag data must be > > self-contained and cannot include pointers to anywhere outside of > > that tag data. > > Very true, but the TIFF specification is contradictory, and IFD's > defined in the standard are allowed to violate this rule. Strictly speaking, one could argue that the documented exceptions to the rule are the only allowed exceptions, but allowed exceptions nonetheless. These include the IFD datatype itself and LONG datatype used as IFD pointer, and the StripOffsets and TileOffsets tags. So these require special handling in software, sure. The thing is, they're documented, part of the spec, and so special handling is possible. The same does not apply to any private tags, for example. > > b) is not a problem if you don't copy tags you don't fully know, > > like I recommended Anurag in the first place though he didn't seem > > to think that recomendation was worth considering. > > True again, but I would never take my car to a mechanic who simply > discards the parts he doesn't fully understand. Strictly speaking, it wouldn't be that much of a problem if a) the car is considered to be a means of transportation and any added functionality beyond that is considered private functionality that may very well become incorrect due to alien mechanics interfering. b) the mechanic has a full understanding of all bits involved in the transportation functionality, and the other way around, the mechanic is guaranteed that no additional bits that he might not understand interfere with the transportantion functionality. This sort-off applies to TIFF, being regarded as a means of image interchange, and private tags not being allowed to interfere with image rendering interpretation. > I'm just venting because this > touches on some aspects of the TIFF specification which I find very > unfortunate. I will immediatelly admit this all is... Well, I'm not sure I'd use the word 'unfortunate' since it's hard to come up with a better alternative that still suits all of the primary goals TIFF covers. But I do fully understand your pain. And for at the very least part of this stuff, more precisely the datatype LONG being valid for IFD pointers, I do fully agree to use the word 'unfortunate'. Anyways, we've a mailing list where many people end up asking question sooner or later, so if we make our points time and time again, we can contribute and help people not fall in the obvious traps when at least they consider our advice. Best regards, Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html