Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas022.isp.belgacom.be (localhost [127.0.0.1])
        by inav003.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k34MIRKE019191
        for <joris.at.lebbeke@skynet.be>; Wed, 5 Apr 2006 00:18:27 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.5.90])
        by inas022.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k34MIKo7031083
        for <joris.at.lebbeke@skynet.be>; Wed, 5 Apr 2006 00:18:22 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx012.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k34MIFDe021154
        for <joris.at.lebbeke@skynet.be>; Wed, 5 Apr 2006 00:18:15 +0200
        (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 k34MEFbT025889;
	Tue, 4 Apr 2006 18:14:19 -0400
Received: from intranet.diaginc.com (internet.diaginc.com [66.208.219.4] (may
	be forged))
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k34ME8Hh025870
	for <tiff@lists.maptools.org>; Tue, 4 Apr 2006 18:14:08 -0400
Received: from localhost (localhost [127.0.0.1])
	by intranet.diaginc.com (Postfix) with ESMTP
	id 9ACA2499DAE6; Tue,  4 Apr 2006 18:14:05 -0400 (EDT)
Received: from intranet.diaginc.com ([127.0.0.1])
	by localhost (rosetta.local [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 29108-06; Tue,  4 Apr 2006 18:14:04 -0400 (EDT)
Received: from [24.0.188.11] (c-24-0-188-11.hsd1.tx.comcast.net [24.0.188.11])
	by intranet.diaginc.com (Postfix) with ESMTP
	id 08461499DADD; Tue,  4 Apr 2006 18:14:04 -0400 (EDT)
Message-ID: <4432EFC0.2090201@diaginc.com>
Date: Tue, 04 Apr 2006 17:14:24 -0500
From: Larry Michaels <lmichaels@diaginc.com>
Organization: Diagnostic Instruments, Inc. abc
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Chris Cox <ccox@adobe.com>
Subject: Re: [Tiff] BigTIFF Suggestion
References: <C058342F.2AA25%ccox@adobe.com>
In-Reply-To: <C058342F.2AA25%ccox@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at diaginc.com
Cc: TIFF <tiff@lists.maptools.org>, joris.at.lebbeke@skynet.be
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: lmichaels@diaginc.com
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.0000151d
X-MSP-STORE: Wed, 05 Apr 2006 00:18:37 --21-99
Status:   

Our application acquires images from digital cameras and allows images to be stored in sequences which are currently 
TIFF files.  It therefore commonly needs to append new images to existing TIFFs.   Our users may need to save hundreds 
or even thousands of images in a single TIFF file.  I have implemented a few tricks with the LibTIFF code to avoid 
having to walk through the entire directory list each time, but it would be great if the new BigTIFF specification could 
support this capability officially.

I thought that simply adding another eight bytes to the BigTIFF header for an last IFD offset value would provide the 
needed information with minimum disruption to the specification.  The value could be optional; If a BigTIFF writer did 
not want to write the offset value, it could simply write zero to the field.

I realize that this suggestion would have been more appropriate two years ago, but I have only just recently been asked 
to enhance our application's efficient writing of huge image sequence files, and have therefore started investigating 
BigTIFF as an option.


Larry Michaels





Chris Cox wrote:
> How often do applications append something to a TIFF file instead of writing
> the whole file at once?
> 
> I don't think this is a common enough occurrence to change the file format.
> 
> Chris
> 
> 
> On 4/4/06 9:50 AM, "Larry Michaels" <lmichaels@diaginc.com> wrote:
> 
>> I would like to propose the addition of a field to the BigTIFF specification,
>> perhaps in the header, to specify the
>> offset to the last IFD.  This would make the task of appending new images to
>> the end of the BigTIFF file much more
>> efficient than it currently is.  Currently, appending an image requires
>> seeking to each IFD, starting with the first,
>> reading the tag count value, and then seeking to the next IFD offset value
>> until the last IFD is found.  This can be
>> quite time-consuming when appending images to files which already contain a
>> large number of images.  Being able to seek
>> directly to the last IFD would radically improve performance in such
>> situations.
>>
>>
>> Larry Michaels
>>
>>
>> _______________________________________________
>> Tiff mailing list: Tiff@lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/tiff
>> http://www.remotesensing.org/libtiff/
> 
> 
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
