2011.09.28 20:55 "Re: [Tiff] Write Exif data to Tiff file", by Joris Van Damme

Bob,

> I should mention that even though EXIF is defined like a TIFF IFD it is > still actually a binary blob (JPEG-dominated) as far as the world is

> concerned.  If a BigTIFF properly stored an EXIF IFD then the structure > would not actually be EXIF compliant.

I cannot say I remember all involved specifications by heart, nor do I have to time to do intensive investigation right now.

But it seems to me that if there's a conflict between EXIF and BigTIFF, then it should be extremely easy to resolve. Each to his own, simple as that. The "container" is TIFF/BigTIFF, so the IFD and tag structure, and the byteorder, and all that, is TIFF/BigTIFF. The "contained" is EXIF, so the tag IDs and the meaning they represent, is EXIF.

There are plenty of other examples where this straightforward and unambiguous rule has been applied. For example, we use G3/G4 compression on singlebit image data. The TIFF specification simply refers to G3/G4 specifications that in turn define not only a compression algorithm, but also a limited range of image sizes and the interpretation of the values 0 and 1 as black and white (or the other way around, not too sure if my memory serves me correctly here). Everyone has simply decided that the "image container" is TIFF, and so the TIFF specification rules on matters such as sizes and color interpretation. The contradicting elements in the G3/G4 specifications are simply ignored. Each to his own, and that's how the TIFF specification was able to reuse specifications that originated in different contexts.

It's a sort-off universal common sense thing. If you sign a contract that is contrary to the law of your country, the latter applies since it's your 'container' and the contradicting part of the contract simply looses its validity. That may seem like an unrelated example, but in my mind, it shows this is merely common sense and universally applicable. It's how we unambiguously deal with the little imperfections that originate from fitting pre-existing "containeds" in pre-existing "containers", where we would otherwise have to do tons of per-combination tailored fitting.

So I see no real problem. BigTIFF is BigTIFF, and unambiguously specifies IFD and tag structure. EXIF specifies a number of specific tags and their meaning. Historical reasons may have existed to add some more stuff to the EXIF spec, and/or even duplicate some of the TIFF specification, but we do not have those reasons here and we cannot and should not allow a TIFF/BigTIFF application to override the TIFF/BigTIFF specification or old-style-jpeg-hells break loose. Like the contract and the law of the country, when you apply EXIF in TIFF or BigTIFF, it is implied you ignore elements in the EXIF spec that contradict the TIFF/BigTIFF spec.

If my memory is too limited and you feel this common sense approach is impossible or incomplete or ambiguous in resolving all issues, please quote specifications, including page and paragraph references, and I'll gladly stand corrected and thank you for filling those gaps in my perception.

> it is
> still actually a binary blob (JPEG-dominated) as far as the world is
> concerned

What does that mean? How is anything a 'binary blob as far as the world is concerned'? Anything and everything is a binary blob in between encoding and decoding. This particular binary blob, if you're referring to the marker value in a JPEG, is a TIFF. So TIFF spec is the first to apply. In a world were the dominating open source TIFF library would actually be able to deal with TIFF's basic structures, the 'binary blob' would most often be decoded by that TIFF library, most often having been encoded by that same library at some point. So? How does this change or confirm anything at all, or even be relevant? Am I missing your point?

Best regards,

Joris Van Damme
AWare Systems
info@awaresystems.be
http://www.awaresystems.be/

http://lists.maptools.org/