LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
December 2004
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
2004.12.07 11:06 "Re: Having problems adding IPTC to a TIFF", by Joris Van Damme
Eric, Another usefull contribution wasted on me. Please do remember to post on-list. Especially if you agree with me instead. ;-) > I agree with Bob in the sense that plenty of existing software is expecting > a long tag for richiptc, so writing it as undefined would certainly lead to > more problems that what it would solve, provided those software are > presumably aware of the issue, and ready to handle uncorrectly byte-swapped > iptc data. 1. Tolerating bugs, for the sake of backward compatibility with bug compensating software, only leads to validating the bug. Photoshop did that, according to Chris, to compensate for the GraphicsMagic bug. Bob, building from GraphicsMagic rather then reading a spec, next tried to validate the GraphicsMagic behaviour earlier saying that Photoshop did it too. Other software, building on LibTiff, will do it too... I thus believe that in case of so obviously ackward mistake resulting in corrupted data, it is better to make a clean break and correct the mistake. 2. I know of some people interpreting IPTC data from various sources, but not reading IPTC data from TIFF at all. One may wonder howcome. And how many people are left that actually do read the buggy data and compensate for the error. From those last people, I can only assume they thoroughly investiged the problem and its cause, to come up with a solution. Surely, they (and presumably their code) will not be surprised then seeing IPTC data with a correct datatype instead. 3. I can only assume at least some non-LibTiff sources do write the data with correct datatype. Even Bob mentioned two sources (not counting the actual spec) that says the datatype is byte, so not everyone is falling into this trap. So here's another reason to assume an IPTC tag data reader that is robust enough to compensate for the error, will most probably also read the correct datatype. 4. There's some value in truth. Correcting a mistake is a good thing, even if it does come at some cost. 5. You may also wonder what existing software does expect. Due to the structure of the data, and the fact that often times garbadge or zero bytes are appended to the data, any reader will loop through tags as long as it sees the first next byte value equal 0x1C. If it doesn't equal that value, the looping will simply be aborted silently, so as to not fail on the appended garbadge or zero bytes. This scheme, applied to longswapping corrupted data, aborts silently, without any error before reading the very first tag. Thus, I assume most readers that do not compensate for the error, simply read nothing usefull at all. Probably, that's another reason so few people seem to even bother doing anything with this particular heap of IPTC data whilst usefully reading other IPTC data. The result of correcting the mistake would not be breaking a lot of existing readers, because there are very few, but enabling future use instead. In any case, LibTiff users or any sort of TIFF aware person, certainly does *not* expect having to detect long based byte order from the data, and especially not if the data is not long based. I don't think we'll break a lot of expected behaviour, we'll mostly enable usefullness instead. 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
Editor's note: This mail was not originally archived, and has been reconstructed from quotes.