LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.08.08 15:01 "Re: 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