AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
March 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



Valid HTML 4.01!



Thread

2005.03.17 03:43 "libtiff and EXIF", by <ron@debian.org>
2005.03.17 03:53 "Re: libtiff and EXIF", by Bob Friesenhahn
2005.03.17 05:15 "Re: libtiff and EXIF", by <ron@debian.org>
2005.03.17 06:00 "Re: libtiff and EXIF", by Joris Van Damme
2005.03.17 06:21 "Re: libtiff and EXIF", by Joris Van Damme
2005.03.17 16:43 "Re: libtiff and EXIF", by <ron@debian.org>
2005.03.17 17:21 "Re: libtiff and EXIF", by Joris Van Damme
2005.03.17 18:57 "Re: libtiff and EXIF", by <ron@debian.org>
2005.03.17 16:00 "[PATCH] libtiff and EXIF", by <ron@debian.org>
2005.03.17 16:55 "Re: [PATCH] libtiff and EXIF", by Vadim Sukhomlinov
2005.03.18 11:39 "Re: [PATCH] libtiff and EXIF", by Andrey Kiselev

2005.03.17 06:21 "Re: 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