-
2005.08.03 15:27 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Bob Friesenhahn
-
2005.08.08 11:02 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Rob van den Tillaart
-
2005.08.08 11:32 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
-
2005.08.08 13:55 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Rob van den Tillaart
- 2005.08.08 15:01 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
- 2005.08.08 15:18 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
-
2005.08.08 13:55 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Rob van den Tillaart
- 2005.08.08 11:43 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
- 2005.08.09 10:29 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
-
2005.08.08 11:32 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
-
2005.08.08 11:02 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Rob van den Tillaart
2005.08.08 15:01 "Re: [Tiff] Overlay Hyperlinks On TIFF", by Joris Van Damme
Rob,
One question remains: Is it so that tags must be unique? X and Y resolution tags are reused within a multipage tiff file so uniqueness seems to be a per image property for some tags and a per file property for other tags (e.g. Software tag).
Indeed, no tag may occur more then once in a single IFD. Also, no tag in any IFD can apply to any other IFD or the multipage linked list as a whole. You and/or your code may consider a Software tag in one IFD to apply to all IFDs in that file, but, strictly speaking, that is not correct.
Some specs that build on from TIFF deliberatly violate that last rule. For example, RFC2301 defines a private IFD that would be mentioned only ('preferably in the first IFD', they say, but that statement all by itself shows what's wrong with this), and apply as a default to all IFDs in a file.
That's just not TIFF, though, it's a spec violation. (Or perhaps not, see further below.)
So why can a tag not be used e.g. 4 times for a single image. It is the simplest way to implement a dynamic list. I agree that such semantics should be described explicit.
Is it forbidden in the spec?
Yes, it is. (Or perhaps not, see further below.)
It's simply a convention. If it were not forbidden, that would be one more degree of freedom. (Either use the same tag multiple times, or define the tag such that multiple data sets can constitute one tag's data value.) It would also be one more complication to deal with. (What to do when there's multiple occurences of the ImageWidth tag in a single IFD?) And one more complication in the typical interface between codec layer and application layer. (You would not be able to simply ask for the value of XResolution, but you would have to pass an index to what particular XResolution tag you want to query.)
I've tried to locate the exact bits of the spec to quote here... but didn't find them. Going from the assumption that I didn't find them because they aren't there, rather then working from the perhaps more likely assumption that I didn't find them because I've not spend the time reading the whole spec again cover to cover,...
- The fact that each tag must be unique inside an IFD, is also the code logic in LibTiff and such. It's always been generally assumed that this is the spec's intention. And it is said in the spec, at the very least, that 'The entries in an IFD must be sorted in ascending order by Tag.' (section 2 / image file directory / sort order), which you may or may not want to interpret as implying that any tag can occur at most once inside an IFD, and should in any case interpret to mean there is no definition of 'sort order' for more occurences, which would be a problem with your dynamic list anyway.
- The fact that any tag and its value can only apply to the IFD in which it occurs, and cannot have any meaning outside that IFD, is a convention that dates from sime time *after* the TIFF 6.0 spec was written, so it's quite logical there is no mention of this in the TIFF 6.0 spec. It is the same line of thinking that is also demonstrated in the specification supplement that describes the SubIFD tag, is compatible with all tags (for example it is clear that the compression tag in one IFD does not say anything about the compression used in another IFD), and this is also compatible with the unwritten rule that as little as possible should be know about any specific tag in order to present as much functionality on the IFD level as possible. (For example, a library that offers access to a particular IFD and features abstraction from the complete IFD list issues, would have to know what the scopes of all individual tags are in order to do that, if some tags would apply to IFD other then the IFDs they're used in. It would also have to scan the first IFD no matter what, or even any IFD in the list, in order to find and gather all tags that possibly apply to the IFD presented to the app. These complications do not exist if tags only apply to the IFD they're used in.) Similar complication arise when 'deleting' a page by unlinking it from the list. What if it's a page that contains tags that apply to other pages? Etc...
- In short, even if this is not mentioned in the spec, as opposed to simply me not having been able to find it in such short time and/or the multi-IFD-tree structure simply not yet being used/useful in the days when the TIFF 6.0 spec was written, it is a downright necessity for the TIFF file format to make sense and/or an unwritten rule applied in current codecs logic, including LibTiff.
- P.S. Chris Cox' comments on these issues would be nice, him being our 'man in Adobe' and thus something of a God to us TIFFers in the Creating sense. I've put him in the CC list, I hope he doesn't feel I'm imposing these issues on him though.
Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html