2005.03.17 18:57 "Re: [Tiff] libtiff and EXIF", by Ron
- 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.
Ok, I see what you are getting at. I'm not sure we need to add another field to carry this information about though, but yes, its too early to say for sure.
- 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.
Yes, with the exception of this additional member, this is the sort of thing I would like to see evolve. An extensible handler for IFD's like we have already for the tags within them. We want a common structure which captures the simple linked list nature of the basic IFD, and then structures which extend it in their own peculiar fashion. But there are still a few things we can do before taking that leap.
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.
Actually, speaking as a resident of several busy lists that have reply to list as the default, I'm not sure this is a problem :-) A large part of the reason I actually did subscribe to discuss this is because the list does seem very quiet and high s/n. I'm beginning to suspect this contributes highly to that. I have no objection to anyone reposting salient parts of my off list replies here, in fact I encourage it once there is something of common interest. A lot of intermediate mails can go by that might not fit that bill though, and it doesn't help anyone to clutter the archive with them. The discipline to summarise a useful thread is surely easier to muster than the discipline not to post OT remarks.
but now its 5am, so this time I really must go sleep...
cheers,
Ron