LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
December 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.12.13 05:24 "Re: Writing EXIF data?", by Joris Van Damme
Paul, Paul J. Lucas wrote: > > Maybe that is because EXIF private tag values would conflict with > > the public tag space? > > 1. They don't. I would like to clearify this part even if I regretably can't directly contribute a solution for you, since many archive readers and direct subscribers are otherwise bound to be unable to make sense of what is said here. The whole EXIF story is mighty confusing, its history is long, tag namespace implementation in LibTiff is inadequate, and we risk loosing track of how things should be if we don't refocus on the actual spec once in a while. Every IFD in the main chain is supposed to be an image IFD. That's one namespace, the image IFD namespace. Tags in there are grouped into 'baseline tags', that the orignal specification says should be supported by all, 'extension tags', that are nearly equally supported by all by now, and 'private tags'. A TIFF image decoder should have knowledge about first two groups. The third group is what is allocated by Adobe for anyone who wishes to store private data. For the sake of interchangeability, these private tags should not influence intended image rendering. These tags are private, it is up to the owner to decide whether or not to share information about them, but they are in any case not part of the TIFF specification. I assume that is the reason why you feel the EXIF tag is undocumented. It's documented allright, but you won't see it mentioned in the TIFF spec since it is a private extension of TIFF that cannot interfere with its core business being image representation. Some tags may have datatype Ifd, or Ifd8 in BigTiff, and point to one or more chains of child IFDs. The datatype Long can also be used for this purpose, but that is not recommendable. The tag that points to a child IFD, determines the namespace of that child IFD. For instance, the SubIFDs tag points to child IFDs that have image IFD namespace, while the EXIF tag points to a child IFD that has EXIF IFD namespace. When a private tag points to an IFD with namespace different from image IFD namespace, the tags in that child IFD are called 'private IFD tags'. In seperate namespaces, the same tag ID code can occur. For instance, a GPS tag points to a child IFD that has GPS namespace. In this child IFD, the tag ID code 1 means GPSLatitudeRef. An interoperability tag points to a child IFD that has interoperability namespace, and here, the tag ID code 1 means something else. Not properly implementing tag namespaces, LibTiff has troubles with this concept. How is it supposed to define GPSLatitudeRef, or, the other way around, how is it supposed to make sense of tag ID code 1, when it has no clue 'bout namespaces? I assume this issue is what Bob was referring to. EXIF tags, originally, where inserted in main chain IFDs, thus they were private tags living in image IFD namespace. This is the reason no code used in EXIF tags is used in any (other) private tag in image IFD namespace, they originally were part of this namespace! However, at some point, it was rightly decided that EXIF tags encoding was best grouped in a seperate private IFD. Thus came the actual EXIF tag, pointing to a private IFD, in which the same old EXIF tags with the same old codes got written. Thus, EXIF tags actually live in a particular private namespace, too. In a correct TIFF implementation, they should be defined in both these spaces, if they are defined at all (remember, they're 'private', not core TIFF business). In abstractions like the tag directory http://www.awaresystems.be/imaging/tiff/tifftags.html, they are incorrectly mentioned as private IFD tags only to avoid duplication of tag definition pages. LibTiff has a history of trouble with anything but true image IFDs. Well, in fact, it has trouble with SubIFDs too, so it's more correct to say that it has trouble with anything but main chain IFDs. Well, in fact, some bad standards that build from TIFF use secondary IFDs in the main chain to store only private stuff without image data, and LibTiff has trouble reading/writing that, too. It is a know limitation, that is a result from the fact that IFD and tag access support is not generic on the one hand, and too closely tied up with image encoding and decoding on the other hand. While I'm not up to date on all nitty gritty details, I believe this has recently been discussed several times, and solutions may be planned and/or partly implemented. I recommend you do a search over at http://www.awaresystems.be/imaging/tiff/tml.html for more recent posts on this matter. 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