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 05:15 "Re: libtiff and EXIF", by <ron@debian.org>
On Wed, Mar 16, 2005 at 09:53:10PM -0600, Bob Friesenhahn wrote: > > It is intended the libtiff support it, or at least cleanly allow it. > I was about to dive into this myself. Please post a clean patch > against the libtiff CVS version to libtiff's bugzilla at > "http://bugzilla.remotesensing.org/enter_bug.cgi?product=libtiff". > That should hasten getting some support into libtiff. Ok. I'll kick what I have into a form more suitable for actual users and submit it for consideration. Right now I have a TIFFSetExifDirectory function, which is like SetSubdir, except it forwards to TIFFReadExifDir which in turn is a simplified version of TIFFReadDirectory. I'll probably rename them to TIFF{Set,Read}IFD instead, since it can be used to grab GPS and other public-private IFD's too, not just exif. That's enough for exif in tiff. For exif in jpeg we are also going to need a version of ClientOpen that does not automatically read the first dir and expect the first IFD to be tiff. Exif in jpeg starts with a tiff header, but has no primary image IFD with the tiff required tags, so the sanity checks prang.[1] I subverted that by opening it for reading with mode 'a' ; ) but we need something a bit less occult than that I think. I thought briefly about a special flag, but I think we'd be better to just have a generic open function which does not try to read the first IFD as a tiff image, and then (re)implement the existing one (ABI compatibly) in terms of it. [1] - I don't expect we should parse raw jpeg here, (though a wrapper to do that which could fetch just exif wouldn't be hard) but it should be able to accept anything beginning with a valid tiff header and with tiff style IFD blocks in it, even if none of them contain a tiff standard image. TIFFReadIFD would then parse any generic IFD's, matching tags with known FieldInfo and auto registering the rest. Everything else, we get to punt to the user of the tag data who presumably knows something about what they want from it and can build on from here. Anyone have better ideas to add for a first iteration? This seems to be close to the line of least resistance as I see it but I'm the new kid in this code and so all ears still. And is there a good word for these proto-tiff's -- calling the generic open function OpenIFD doesn't sound right, but what does? Anyway, I'll get an implementation up, we can squabble about names later. :-) Thanks! Ron > The harder, but long term more rewarding way, would be to ... > > Perhaps this can be a task for libtiff 4.0. That seems wise if there is a scheduled breakage in the queue.