2006.08.24 07:29 "[Tiff] IPTC tag", by Joris Van Damme

2006.08.25 11:15 "Re: [Tiff] IPTC tag", by Joris Van Damme


It seems we are often more eager to go with the flow, then we are eager to realize we actually participate in designing tomorrow's flow. It's amazing how the same people that routinely advize to 'Write conservatively, read liberally', next write liberally and conservatively read back the bug only, obviously not giving proper attention to the fact that they are propagating a problem instead of merely anticipating one.

You need to special case the IPTC tag to not do byte order swapping, and always read as bytes (the Photoshop parser does this).

You open the door only to more questions. Certainly, if I write Long data into the IPTC tag with LibTiff, into a motorola order file, on an intel order machine (or the other way around), LibTiff *does* swap that data. You can't possibly dissagree on this part, it is a fact. So, I'm left with the questions, if a substantial amount of users suffer from this problem trying to read these TIFF files into Adobe software, would Adobe even be aware? In fact, would all of the users be aware, if Adobe software in this case just reads the TIFF file, and silently skips over the IPTC tag data, as it is viewed to be 'corrupt'?

If (tag == IPTC_tag)
    // calculate the length in bytes from the data type

    // read the number of bytes, ignoring the data type

Again, I would humbly suggest that is bad advice, for the same reason detailed above. If it's a motorola file I'm reading with LibTiff on an intel machine, or the other way around, swapping of the data will occur, either a first or a second time around depending on writer situation that is not directly detectable at this time. In LibTiff, there is no such thing as 'read the number of bytes, ignoring the data type', and swapping will occur when file and machine byte order differs.

I've explained how swapping might have occured before the actual writing, so this feature that is 'undesirable' when implementing the scheme you propose above, may actually render the data valid again, instead of rendering it invalid... Just no way of telling.

Aside from the argument that writing IPTC data as longs propagates a problem as it did for a decade now, whilst it could have been corrected nine and a half years ago, and totally aside from the fact that the reading scheme you propose as being part of Photoshop simply does *not* work on part of the files out there, as I've clearly shown, some people doing the wrong thing are opening themselves up to legit user complaints. Sooner or later someone is going to do the wright thing, and write undefined data into the IPTC tag, if nobody's doing that already. I have no current interest in the IPTC tag, but surely enough, if tomorrow some interest comes along, I'll be writing undefined data into the IPTC tag. If next my software conflicts with any other, *I* will be the one answering to user complaints that at least I'm doing the valid thing, and that most vendors who are incompatible with those valid ways, are very well aware of it, too.

In general, my conclusions stands. I'm not satisfied with recommending ways to be compatible only, nor with applying these ways myself. I need to recommend to exercise some way that is compatible when reading today's mess, but also aids in evolving towards respecting the TIFF specification and clearing the road for tomorrow's programmers wanting to do the same tag. In other words, I plan to write conservatively, and read liberally, and I don't know of anybody who ever argued that wasn't a sain principle. If I did know any such heretic, I figure he would be reading *and* writing OJPEG, and not supporting new-style JPEG in TIFF at all, defending his case saying it was necessary to 'make it work with the WANG imaging software', or something.

Joris Van Damme
Download your free TIFF tag viewer for windows here: