Return-Path: <tiff-bounces@lists.maptools.org>
Received: from infbas001.isp.belgacom.be (localhost [127.0.0.1])
        by inav014.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AV-3.00) with ESMTP id jBMM9d3o029038
        for <joris.at.lebbeke@skynet.be>; Thu, 22 Dec 2005 23:09:39 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inas006.isp.belgacom.be (inas006.isp.belgacom.be [195.238.2.10])
        by infbas001.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id jBMM9c5g020676
        for <joris.at.lebbeke@skynet.be>; Thu, 22 Dec 2005 23:09:38 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx005.isp.belgacom.be (inmx005.isp.belgacom.be [195.238.5.148])
        by inas006.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AS-2.03) with ESMTP id jBMM9SCf012690
        for <joris.at.lebbeke@skynet.be>; Thu, 22 Dec 2005 23:09:29 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id jBMM9JlN026358
        for <joris.at.lebbeke@skynet.be>; Thu, 22 Dec 2005 23:09:19 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id jBMM2afU017474;
	Thu, 22 Dec 2005 17:03:19 -0500
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id jBMM2ZAT017471
	for <tiff@lists.maptools.org>; Thu, 22 Dec 2005 17:02:35 -0500
Received: by zproxy.gmail.com with SMTP id i28so542575nzi
	for <tiff@lists.maptools.org>; Thu, 22 Dec 2005 14:02:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=tI0svBf1RY6ujO5nvTQdltC8wyJD/JNv0COpeKq4ZNl0Huxv+ylenQKFxA1GpMAMtZofOQxZ1YrnSh5x7IXbCxFstGkQ+hsizMGR3EoAeuksAoGyPxVW2TCupCv7X+50fLbBM52w4HpABstS8OJh4/Ueny6X+s91VCc79tr1YX8=
Received: by 10.65.83.3 with SMTP id k3mr552810qbl;
	Thu, 22 Dec 2005 14:02:33 -0800 (PST)
Received: by 10.65.151.20 with HTTP; Thu, 22 Dec 2005 14:02:33 -0800 (PST)
Message-ID: <931f8ea90512221402q599b33f1j3706a11239422e97@mail.gmail.com>
Date: Thu, 22 Dec 2005 17:02:33 -0500
From: Frank Warmerdam <warmerdam@pobox.com>
To: Chris Losinger <losinger@earthlink.net>
Subject: Re: [Tiff] filtering TIFF tags
In-Reply-To: <6.0.0.22.1.20051222145756.01d33448@pop.earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <6.0.0.22.1.20051222145756.01d33448@pop.earthlink.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by duke.maptools.org id
	jBMM2ZAT017471
Cc: tiff@lists.maptools.org
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.0000101f
X-MSP-STORE: Thu, 22 Dec 2005 23:09:42 +0100
Status:   

On 12/22/05, Chris Losinger <losinger@earthlink.net> wrote:
>
>          either would be fine, for my immediate needs. and, i'll probably
> end up hacking something in, if there's no built in support.
>          but your 'lazy' mechanism would be ideal.

Chris,

I am concerned about this too.   My application can end
up re-reading directories quite a bit (as different levels of
overviews are accessed for instance) and it seems like
the directory reading cost could be quite high.

In addition to "big metadata", I also see this happening
with big tile/strip size/offset arrays.  In a BigTIFF world,
for instance, it would be easy to have files with a million
tiles.

It should be pretty easy to make the code that reads
custom (ie. generic) tags do so in a lazy fashion.  But
it could be pretty hard for the tags that are loaded directly
into the tiff directory structure as other code then just
assumes they can be accessed at will.

Perhaps we could look at doing something for the
custom/generic tags first which would solve your problem
with big metadata values.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
