AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2005.03.17 05:15 "Re: [Tiff] libtiff and EXIF", by Ron
2005.03.17 03:42 "[Tiff] libtiff and EXIF", by Ron
2005.03.17 03:53 "Re: [Tiff] libtiff and EXIF", by Bob Friesenhahn
2005.03.17 06:00 "Re: [Tiff] libtiff and EXIF", by Joris
2005.03.17 06:21 "Re: [Tiff] libtiff and EXIF", by Joris
2005.03.17 16:43 "Re: [Tiff] libtiff and EXIF", by Ron
2005.03.17 17:21 "Re: [Tiff] libtiff and EXIF", by Joris
2005.03.17 18:57 "Re: [Tiff] libtiff and EXIF", by Ron
2005.03.17 16:55 "RE: [Tiff] [PATCH] libtiff and EXIF", by Sukhomlinov, Vadim
2005.03.17 16:00 "[Tiff] [PATCH] libtiff and EXIF", by Ron
2005.03.18 11:39 "Re: [Tiff] [PATCH] libtiff and EXIF", by Andrey Kiselev

2005.03.17 05:15 "Re: [Tiff] libtiff and EXIF", by Ron

On Wed, Mar 16, 2005 at 09:53:10PM -0600, Bob Friesenhahn wrote:

> On Thu, 17 Mar 2005, Ron wrote:
>
> >I've been looking at what is required to parse exif data using libtiff,
> >and it looks like surprisingly little. It was trivial to bypass enough
> >sanity checks to easily get it to recognise and read the ExifIFD and
> >auto register all the tags it found there. And not that much harder to
> >get it to recognise a similar tiff'ette extracted from the APP1 section
> >of a jpeg file with exif data and then fed to libtiff.
> >
> >So the biggest question is how you all feel about supporting this from
> >libtiff. Obviously TIFFFieldInfo for exif tags, if people wanted them,
>
> 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.