Return-Path: <tiff-bounces@remotesensing.org>
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx009.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j2U7rdN4005285
        for <joris.at.lebbeke@skynet.be>; Wed, 30 Mar 2005 09:53:41 +0200
        (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 A8490193E54F; Wed, 30 Mar 2005 02:53:18 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx020.isp.belgacom.be (outmx020.isp.belgacom.be
	[195.238.2.201])
	by xserve.flids.com (Postfix) with ESMTP id B9E05193E52C
	for <tiff@remotesensing.org>; Wed, 30 Mar 2005 02:53:15 -0500 (EST)
Received: from outmx020.isp.belgacom.be (localhost [127.0.0.1])
	by outmx020.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id j2U7rCdF007295
	for <tiff@remotesensing.org>; Wed, 30 Mar 2005 09:53:12 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (91-153.246.81.adsl.skynet.be [81.246.153.91])
	by outmx020.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id j2U7r6qm007243
	for <tiff@remotesensing.org>; Wed, 30 Mar 2005 09:53:06 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <001801c534fd$b30fe220$5b99f651@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: <tiff@remotesensing.org>
References: <20050330001802.GB4298@hank.shelbyville.oz><Pine.SOC.4.60.0503292118290.8945@blade.simplesystems.org>
	<20050330055510.GA10045@hank.shelbyville.oz>
Subject: Re: [Tiff] RFC: fast 'copy free' tiff decoding
Date: Wed, 30 Mar 2005 09:54:27 +0200
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
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: 000000000023ceae.0000002a
X-MSP-STORE: Wed, 30 Mar 2005 09:54:01 +0200
Status:   

Ron,

> How to handle subsets of the available data is probably the most
> pressing one.  Without handling them more than necessary and without
> losing data that I have incomplete knowledge about.

May I resume your goal like this...?

LibTiff offers no generic access to TIFF (Tag) data as it is. Instead, it goes a
long way interpreting (checking tag datatype and count for starters), and next
offers tag specific access that may be substantially different from the original
tag data (like is the case with the Colormap tag, or even the count of the
BitsPerSample tag). That is fine if your code at some point really needs a
convinient single value for specifically the BitsPerSample tag, but it is a
bridge too far if you really need more generic access to the exact TIFF (Tag)
data of any tag, in any TIFF.

What is needed is something like 'two layers' of data access here. The bottom
one being the one you propose to add, that simply offers exactly what is there
without doing any sorts of interpreting. This layer does not even need tag
definitions, it is tag ignorant. The next layer, is the layer we're used to in
LibTiff, the layer that is friendly in checking the tag values and interpreting
them, offering access to more higher level structures depending on the specific
tag in question.

If this is your actual goal, I must say I find it a good and natural and correct
thought... At the risk of sounding boring: I've done the same in my native
Delphi TIFF codec. But it is a major rewrite to get it into LibTiff...

If I'm interpreting your goals correctly, I'm afraid you might be confusing the
issue with all this talk about memory maps and other implementation issues. I've
personally always considered memory mapping TIFFs a bad idea. There's no telling
what size files you might need to handle, especially with the new BigTIFF
format. You could need to eat 8 gig of address space on a machine that is
theoretically limited to 2 gig for memory maps, and shares this 2 gig with other
applications, like I think is the case on common windows systems. Moreover,
there seems very little benefit to abusing address space like this, as opposed
to good ol' plain file IO, especially given the fact that you'll need to aling
and byteswap in seperately allocated memory blocks anyhow.


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
