2004.11.13 16:25 "Re: [Tiff] EXIF tags", by Andrey Kiselev

I agree it is not of primary significant importance. You'll need to add the concept of 'tag namespace' to LibTiff anyway, to support EXIF IFDs, if that's what you're doing, and in either case, it does seem to be the right way to handle it and does not seem to yield any problem.

Such a concept already exist in libtiff. We have a static tiffFieldInfo[] array which contains all 'known' tags. We can create similar arrays for tags defined in the private IFDs. Such arrays also can be allocated dynamically. And that is the way I want to use to support EXIF.

I just found that I can't view EXIF info from the TIFF files. My Linux distribution contains two utilities to read EXIF (exif and exiftag, if sombody interested), but both of them works with JPEG files and can't read TIFFs! So I decided to add the missed functionality to libtiff, because all required code already there and we just need to implement several high-level functions. (Side note: I need a samples of the TIFFs with the embedded EXIF subdirectories. If someone has such files, please, share them with me, it helps me a lot).

My understanding is that EXIF, as it is today (private IFD oriented) is similar to Rome in that it wasn't build in a day. Early day attempts at adding some EXIF information to TIFF files was private tag oriented, rather then private IFD oriented. That is why to this day some EXIF tags are legit private tags, as well as private EXIF IFD tags, which explains their numerical range. When the private EXIF IFD scheme came about, the early day private tags simply got duplicated to the EXIF IFD private namespace, and the new additional tags in that private namespace got a code in the same numerical range...

So, in short, this suspicious numerical range is probably explained by history.

Yes, it looks like you are right on this.

Andrey

Andrey V. Kiselev
Home phone: +7 812 5970603 ICQ# 26871517