2004.06.29 13:04 "Re: [Tiff] Saving Exif with TiffLib", by Joris Van Damme
Exif gets promoted to an IFD and there is nothing criminal because this directory shoudn't be visible in a common way. Offset to this directory will not be placed anywhere except the ExifTag. And any "good" reader will just skip unknown tag, as specified by Tiff standart.
Not true, I believe. For instance, a tiff concat that builds a multipage file out of a series of exiffed single page files, will look upon the private tag as an ordinary value tag, not a IFD pointer tag. I'm guessing the type is long and count is 1, right? In that case, the concat app will see this as a normal 32bit value, situated inside the IFD, and simply copy that value. Next, an EXIF aware reader might come along, interpret the value as a pointer to an IFD, but this pointer will now be invalid and the EXIF reader will not be able to make sense of what is being pointed.
I believe the standard says that there should be no offsets in data (other then the 'known offsets' like in the TileOffsets and SubIFD data and such). I believe this is where the EXIF scheme fails to comply.
The problem is how to write such subdirectory using another offset tag (not subifd tag provided by TiffLib).
That's where you need the LibTiff Gods, Andrey and/or Frank. I couldn't say.
But in any way, thanks for your letter, it is rather pleasant to get answer so quick.
No problem. The only TIFF testfile I've got that has EXIF data, is going about it in another way. The first IFD contains the image. It points to the second IFD in the usual way. This second IFD is the horrible EXIF IFD. This scheme is worse then what you're after, in some regards, and better in others... But anyway, I'm always on the lookout for new files in my testfile library, and I'd very much appreciate receiving an EXIF TIFF that complies with the scheme you've talked about, if you've got any. You can send it to email@example.com, if you wish.
Joris Van Damme
Download your free TIFF tag viewer for windows here: