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
Thread
2005.03.17 17:21 "Re: libtiff and EXIF", by Joris Van Damme
Ron, > don't let those C guys go getting airs on you... now us C++ coders... > :-) I'm afrain I'm not C++ either... Haven't activelly written any C or C++ for the better part of ten years or so (not counting though). Though I was a C coder before, I consider myself exclusivelly a Delphi coder these days. > but if we start moving fields about in structures > then binary compatibility will be broken. (ABI = application binary > interface) Yes, Bob already explained that this was part of ABI, where I before was under the impression that the only thing that couldn't change was the function declarations. > > - 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'm not sure I follow on this, the ExifIFD tag is registered (or at > least published in a widely accepted standard, which is good enough > for me if not adobe ;-) so we already know this is its intent. Yes, we do. I'm not talking about us though, but about LibTiff, about the const TIFFFieldInfo array defined in tif_dirinfo.c. LibTiff currently has no indication that a tag of datatype long is intended to point to an IFD. > > - Adding such private, seperate field info name-spaces (I suspect I can save > > typing by generating the proper C source format from the Tag Directory data). > > or what you mean here, though I always like generating things that > otherwise need to be typed. Private IFD tags live in their own, private IFD name-space. For instance, if I register my own private tag with Adobe, and next use it to point to my own private IFD, then I'm free to use tag code 256 inside that IFD to mean anything. There is no conflict between my private IFD tag 256, and the ImageWidth tag, even though both have the same code, because they live in seperate name-spaces. Here's another more real example. Is tag code 1 undefined, or is it the GPSLatitudeRef tag, or is it the InteroperabilityIndex tag? It depends on what IFD it's in. In the image IFD namespace, it's not defined, in the GPS IFD namespace, it's GPDLatitudeRef, etc. This is why, if we are to extend LibTiff with true and good private IFD handling, we'll need to add the notion of seperate tag namespaces. We will also need to add this extra member to the the fieldinfo definitions that says for the EXIF IFD in the image IFD namespace, that it points to an IFD in which the EXIF IFD namespace applies as opposed to e.g. the image IFD namespace or GPS IFD namespace. Thus, I was thinking that an IFD its 'namespace index' is a perfect indication for an extended TIFFReadDirectory function to 'know' if it needs to do its normal image IFD processing or not. But I understand now there is no way we can at this time add an extra member to the TIFFFieldInfo structure, this would break ABI. Nevertheless, I feel the above is the 'true' implementation, it is the solution as lies embedded in the problem, so at the very least we should try to work towards this as far as is possible without breaking anything. > I do like to plan for both long and short term with code like this. Exactly. I wasn't very clear in my mails to the list. Would you mind posting this reply that I'm replying to here to the list, so that I can next also post this clearification? In general, we should really try to keep things on-list. You've noted there is very little on-list talk on the subject, and part of this problem is caused by people moving all interesting discussion off-list, leaving the archive with unanswered questions and unfinished discussions. Best regards, Joris
Editor's note: This mail was not originally archived, and has been reconstructed from quotes.