2004.12.07 17:06 "Re: [Tiff] Having problems adding IPTC to a TIFF", by Eric Vergnaud

Another usefull contribution wasted on me. Please do remember to post on-list. Especially if you agree with me instead. ;-)

Another proof that there's no way I can remember this. I'm using more than 50 lists. Libtiff is the only one that is not allowing me to simply reply to the list.

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.

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.

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.

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.

There's some value in truth. Correcting a mistake is a good thing, even if it does come at some cost.

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.

Well maybe the first thing to do would be to see what Photoshop IS doing. Since Adobe is in charge of the TIFF specs, if they're writing IPTC as a LONG array, then THAT IS the spec, even if it's conceptually incorrect. If they're writing UNDEFINED of whatever, then libtiff should definitely follow.

-------------------------------
Eric VERGNAUD - JLynx Software
Cutting-edge technologies and
services for software companies
web: http://www.jlynx.com
-------------------------------