2004.12.02 18:07 "[Tiff] Having problems adding IPTC to a TIFF", by Roland
Rabien
Thread
2004.12.06 22:52 "Re: [Tiff] Having problems adding IPTC to a TIFF", by Joris Van Damme
This problem should be fixed in CVS (i.e., in post-3.7.0 code). Please, try to fetch the most recent snapshot and test your code with it.
A while ago (http://www.asmail.be/msg0055489739.html), I mentioned that the IPTC tag datatype, TIFF_LONG according to LibTiff code, was suspicious. Other sources mentioned datatype TIFF_BYTE or TIFF_ASCII. Having in mind byte order issues, it seemed strange that a tag could be defined as having either an 8bit or 32bit datatype.
Thanks to Chris Losinger (Thanks, Chris!), I now have the data structure layout of the IPTC data, which seemed not readily present in the specification. (Or either I'm to stupid and/or lazy to wade through a lot of mystical stuff that is not clearly preceded by data structures and such.) The data structure contains byte values, word values and cardinal values that define a set of tags, each of which has specific other data that can have any sort of structure. Thus, the IPTC tag datatype should clearly be TIFF_UNDEFINED, or TIFF_BYTE which is functionally the same.
I tested this newly acquired knowledge on some TIFFs. With some of them, it makes perfect sense. Some others make sense only after unswapping the bytes, ie, at some stage the data has incorrectly been byteswapped as if it were an array of 32bit values which it is not. These others also typically have a too large count. Clearly, these are written by LibTiff with a wrong datatype definition.
My questions are:
- Is the datatype corrected in this newer CVS version? Is that part of the mentioned bugfix? If it is not, will you correct it so as to stop LibTiff writing any more TIFFs with corrupted (!) IPTC data in the future?
- A quick and dirty method to see if IPTC tag data has been incorrectly byteswapped, is testing the first byte. If it is not equal to 0x1C, then most probably the fourth byte of the data is equal to 0x1C, and you need to unswap it to recover the correct data. In that case, the tag count may be unreliable too, so the reader needs to be build to read whatever it can up to the point where the data stops making sense. Does such a robust reader that recovers from LibTiff's data corruption seems sensible to you guys?
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