Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx015.isp.belgacom.be (inmx015.isp.belgacom.be [195.238.2.218])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j2H5GATe032685
        for <joris.at.lebbeke@skynet.be>; Thu, 17 Mar 2005 06:16:10 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx015.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j2H5FsiW007943
        for <joris.at.lebbeke@skynet.be>; Thu, 17 Mar 2005 06:15:55 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 7F38915DB582; Thu, 17 Mar 2005 00:15:38 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from hank.shelbyville.oz (ppp52-227.lns1.adl2.internode.on.net
	[150.101.52.227])
	by xserve.flids.com (Postfix) with ESMTP id 900FE15DB572
	for <tiff@remotesensing.org>; Thu, 17 Mar 2005 00:15:35 -0500 (EST)
Received: from ron by hank.shelbyville.oz with local (Exim 4.50)
	id 1DBnLx-0003N4-1C
	for tiff@remotesensing.org; Thu, 17 Mar 2005 15:45:25 +1030
Date: Thu, 17 Mar 2005 15:45:25 +1030
To: tiff@remotesensing.org
Subject: Re: [Tiff] libtiff and EXIF
Message-ID: <20050317051525.GB610@hank.shelbyville.oz>
References: <20050317034228.GA610@hank.shelbyville.oz>
	<Pine.SOC.4.60.0503162148010.8945@blade.simplesystems.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SOC.4.60.0503162148010.8945@blade.simplesystems.org>
User-Agent: Mutt/1.5.6+20040907i
From: Ron <ron@debian.org>
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 4af88c7e73c984f3eb0da60cc37b5fa6

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.


_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
