Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx016.isp.belgacom.be (inmx016.isp.belgacom.be [195.238.2.219])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j2H60aFW014341
        for <joris.at.lebbeke@skynet.be>; Thu, 17 Mar 2005 07:00:36 +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 inmx016.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j2H60E2H008238
        for <joris.at.lebbeke@skynet.be>; Thu, 17 Mar 2005 07:00:15 +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 0798B15DBA4E; Thu, 17 Mar 2005 00:59:56 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx015.isp.belgacom.be (outmx015.isp.belgacom.be
	[195.238.2.87])
	by xserve.flids.com (Postfix) with ESMTP id ECE7515DBA2B
	for <tiff@remotesensing.org>; Thu, 17 Mar 2005 00:59:52 -0500 (EST)
Received: from outmx015.isp.belgacom.be (localhost [127.0.0.1])
	by outmx015.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id j2H5xnVN014310
	for <tiff@remotesensing.org>; Thu, 17 Mar 2005 06:59:50 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (64-172.245.81.adsl.skynet.be [81.245.172.64])
	by outmx015.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id j2H5xjEs014296; Thu, 17 Mar 2005 06:59:45 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <000f01c52ab6$a9e1f720$40acf551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>, "Ron" <ron@debian.org>
References: <20050317034228.GA610@hank.shelbyville.oz>
	<Pine.SOC.4.60.0503162148010.8945@blade.simplesystems.org>
Subject: Re: [Tiff] libtiff and EXIF
Date: Thu, 17 Mar 2005 07:00:44 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Cc: tiff@remotesensing.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: d8029e5d35c09dd8e14b25b2a1370fea

> Perhaps this can be a task for libtiff 4.0.

I'm not a C coder, so what the heck do I know, but I still stand by what I
suggested way back in http://www.asmail.be/msg0054569097.html and subsequent. I
feel this would *NOT* have to break current call protocols.

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.
- 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).
- 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.
- 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.
- New stuff can now be added to call TIFFReadDirectoryNs with a specific tag
name-space that can for instance be the EXIF name-space. An example of such new
stuff could be a TIFFSetExifDirectory function, similar to the current
TIFFSetSubDirectory.

Please be patient if I'm being stupid, I'm not a C coder and don't even have a
clue what ABI is.

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?


Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

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