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 16:43 "Re: libtiff and EXIF", by <ron@debian.org>
Hi Joris, On Thu, Mar 17, 2005 at 07:00:44AM +0100, Joris wrote: > > Perhaps this can be a task for libtiff 4.0. > > I'm not a C coder, so what the heck do I know, don't let those C guys go getting airs on you... now us C++ coders... :-) > but I still stand by what I > suggested way back in http://www.asmail.be/msg0054569097.html Yes, I saw that. What surprised me more was that it was the only discussion that I found on the subject, which was why I asked. > and subsequent. I > feel this would *NOT* have to break current call protocols. It doesn't _have_ to, cf. the patch I just posted, but if we abstract out a generic IFD parser its going to start looking attractive for maintenance and other reasons. We might not even need to break source compatibility, but if we start moving fields about in structures then binary compatibility will be broken. (ABI = application binary interface) People won't need to change their code, but distributors of binaries will need to recompile all their apps to use the new libtiff shared lib. > 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'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. > - 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. > - Reworking the current TIFFReadDirectory to take an additional parameter. This > additional parameter is the tag name-space index. Thus, 0 means image IFD, 1 > could mean EXIF IFD namespace, etc. This reworked TIFFReadDirectory is made to > skip most of its normal image IFD specific handling if the name-space index is > not 0, and can thus work on EXIF IFDs. What do we get from this that we don't already have from the ability to call TIFFMergeFieldInfo, without needing to enumerate the tag sets it may be called with? > - To not break current call protocol, make this reworked TIFFReadDirectory a new > function, say TIFFReadDirectoryNs. The new implementation of > TIFFReadDirectory(...) is then simply a call to TIFFReadDirectoryNs(...,0). > Current calls of TIFFReadDirectory are thus not broken, the call protocol of > this function is not changes, and it still does exactly what it currently does, > i.e. read an image IFD. Yes, that is more or less what I have done. The real 'breakage' I was referring to comes from the fact that the 'struct TIFF' contains a lot of stuff that is tiff specific, yet we must still use it for these generic IFD's. If we break it into common and tiff specific parts, we also break binary compatibility, even if all the field names and calling conventions remain the same. > My question is, is the above suggested scheme, that does no break consistency > and does not involve code duplication, breaking any applications or any sorts of > ABI whatever it is? If not, is it feasable and sufficient? In the short term, while we look at what people need from this, yes it is probably sufficient. It does involve redundancy and duplication though. We are trying to solve a more general problem than the code was originally written to handle, which usually means ultimately rewriting the original code in terms of the new foundation, even if that is not what you set out intending to do. But this is precisely why we can delay changes like this until a major new release and make all binary incompatible changes at once. I do like to plan for both long and short term with code like this. cheers, Ron
Editor's note: This mail was not originally archived, and has been reconstructed from quotes.