2004.12.02 18:07 "[Tiff] Having problems adding IPTC to a TIFF", by Roland Rabien

2004.12.07 09:11 "Re: [Tiff] Having problems adding IPTC to a TIFF", by Joris Van Damme


Photoshop can read it with any tag type, but writes as type long for compatibility with some unspecified application (and the comment has been in there a long time).

Does Photoshop compensate for long-swapped corrupted data(*)? If it does, what is its criterium? What course of action do you recommend?

(*) For clearity:

The structure is the following, and the same as the first few bytes of every IPTC tag in the structure:

If the most significant bit of the datalength word is set, then the datalength is not actually the datalength, but the most significant bit should be cleared, and the value should be taken to be the number of bytes that follow and the actually do make the datalength. For example, if it is (32768 or 4), then 4 bytes follow that together or the datalength motorola-order long.

Next follows the actual IPTC tag data. The length of that data is not restricted to multiples of two bytes or anything, it can be 3 or it could be 4.

Next follow no pad bytes, and if there's more tags to follow, the IPTC tag structure is repeated.

What happens now if the data is byteswapped as if it were an array of long, is that any IPTC tag reader does not find the data in the expected place. The 0x1C byte, for example, is not at offset 0 but at offset 3, the record ID byte is not at offset 1 (expected), nor at offset 4 (expected if the reader skips to 0x1C for robustness), but at offset 2. Thus, the only way the reader can make sense of it, is by again byteswapping as if it were an array of long. Thus, if an intel machine writes a motorola-order TIFF, and feeds LibTiff proper data, the data is byteswapped, and the reader has to byteswap again, even if it runs on a motorola machine.

A reader that knows about LibTiff's wrong datatype and incorrect long array byteswapping corruption, could compensate by checking the offset of the 0x1C value. If it is not found at offset 0, but is found at offset 3, a reader might assume this particular corruption, and long array byteswap again. This is what I mean by 'compensate for long-swapped corrupted data'. Does Photoshop do that?

A writer that writes out the data with datatype long, can choose to either not byteswap even though when the incorrect datatype long imlies swapping, or corrupt the data. Which of these two options does Photoshop go for? (That is, assuming Photoshop has the ability to write TIFF byteorder that is non-native to the machine, otherwise this is not an issue.)

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