2005.03.17 06:21 "Re: [Tiff] libtiff and EXIF", by Joris Van Damme

I'm not a C coder, so what the heck do I know, but I still stand by what I suggested way back in http://www.asmail.be/msg0054569097.html and subsequent. I feel this would *NOT* have to break current call protocols.

I suggest:

• Adding a single field to current field info constants. This field would be 0 for most tags. For ExifIFD tag, it would be non-zero, indicating that the tag has IFD pointing intent, and also indicating the index into private, seperate field info name-spaces.

I forgot to mention part of what I was thinking of. In what I wrote earlier, this extra member of the field info constants is not necessary. For instance, the TIFFSetExifDirectory function can be implemented without it, as long as there are seperate arrays of constant field definitions, and the reworked TIFFReadDirectory, now TIFFReadDirectoryNs, receives this extra parameter indicating the namespace.

This extra member of the field info constant would however enable another, most general addition, being a sorts of TIFFGetFieldDirectory function. This one starts with a TIFFGetField call to retrieve a LONG/IFD value, and checks the field info definitions to retrieve the namespace index of the pointed IFD. It next used TIFFReadDirectoryNs to read the particular IFD. It is thus a most general 'read private IFD' function, which surely many people need. We could also add a special namespace index for 'unknown name-space', and the auto-registration of unknown tags that are encountered with datatype IFD can be registered with this special unknown namespace index.

Etc. But if a new member of the field info constants breaks any ABI whatever, it is not necessary at least to finally implement EXIF reading for instance without breaking the spirit of the library or adding duplicate code. Right?

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