Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-i.one.com (mx-i.one.com [91.198.169.56])
	by mail6.local (Postfix) with ESMTP id EB65280150C21
	for <filtered@awaresystems.be>; Tue, 27 Nov 2012 03:24:09 +0100 (CET)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-i: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.212.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48])
	by mx-i.one.com (Postfix) with ESMTP id 871572328777
	for <filtered@awaresystems.be>; Tue, 27 Nov 2012 02:24:09 +0000 (UTC)
Received: by mail-vb0-f48.google.com with SMTP id l22so13424864vbn.21
        for <filtered@awaresystems.be>; Mon, 26 Nov 2012 18:24:08 -0800 (PST)
Received: by 10.52.179.130 with SMTP id dg2mr19304157vdc.8.1353983048607;
        Mon, 26 Nov 2012 18:24:08 -0800 (PST)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.58.144.166 with SMTP id sn6csp414172veb;
        Mon, 26 Nov 2012 18:24:07 -0800 (PST)
Received: by 10.220.231.65 with SMTP id jp1mr21830852vcb.30.1353983046007;
        Mon, 26 Nov 2012 18:24:06 -0800 (PST)
Received-SPF: neutral (google.com: 91.198.169.58 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=91.198.169.58;
Received: by 10.220.204.77 with POP3 id fl13mf7167644vcb.4;
        Mon, 26 Nov 2012 18:24:05 -0800 (PST)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-k.one.com (mx-k.one.com [91.198.169.58])
	by mail6.local (Postfix) with ESMTP id 4025880150C21
	for <info@awaresystems.be>; Tue, 27 Nov 2012 03:11:57 +0100 (CET)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-k.one.com (Postfix) with ESMTP id D85F9BC1826
	for <info@awaresystems.be>; Tue, 27 Nov 2012 02:11:56 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id C9E2443A01E;
	Mon, 26 Nov 2012 21:10:25 -0500 (EST)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198])
	by lists.maptools.org (Postfix) with ESMTPS id 7274843A01E
	for <tiff@lists.maptools.org>; Mon, 26 Nov 2012 21:10:03 -0500 (EST)
Received: from new-host.home (pool-74-98-195-11.pitbpa.fios.verizon.net
	[74.98.195.11]) (authenticated bits=0)
	by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id qAR2A6kl028716
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 26 Nov 2012 21:10:06 -0500 (EST)
Message-Id: <5E448839-1E90-4D18-9BB7-169F9B10D69E@cs.cmu.edu>
From: Paul Heckbert <ph@cs.cmu.edu>
To: Daniel McCoy <mccoy@pixar.com>
In-Reply-To: <20121126203306.GD16430@pixar.com>
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 26 Nov 2012 21:10:05 -0500
References: <34716184.post@talk.nabble.com>
	<CA+NZCsQ40xv+Pp=bV9c4uxPkMGFF6o5R6BZ96Z3PPZkFatV3aQ@mail.gmail.com>
	<CAAcuQeasm4-maUa2nB2P4T9Fnx+MeiaEBOEv7RqG7fCMehXkDA@mail.gmail.com>
	<50B216A9.6020902@sidefx.com>
	<CA+NZCsQWWzTP=MePuVkSjODJwKDx3td_DsXqZsuvm68kXnnn-A@mail.gmail.com>
	<20121126203306.GD16430@pixar.com>
X-Mailer: Apple Mail (2.936)
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: Tiff List <tiff@lists.maptools.org>
Subject: Re: [Tiff] help writing thumbnails to TIFF file?
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

We have several opinions so far:
Daniel McCoy said he implemented TIFFCheckpointDirectory years ago to  
allow partially-written TIFF files to be read.
Olivier Paquet and Edward Lam said that they use this function for  
that purpose, and it works for them.  Edward thinks that most other  
people should not use TIFFCheckpointDirectory.
Joris Van Damme referred to the function as a hack that served a  
mysterious function for its original developers.  He added that it  
would be unlikely to suit me or anyone else but he didn't explain why  
it wouldn't, other than to compare TIFFCheckpointDirectory to  
Stonehenge.  He argued that people shouldn't care about the order of  
data in their TIFF files.

I side with those that are saying that TIFFCheckpointDirectory is  
useful and (at least sometimes) works properly.  Without  
TIFFCheckpointDirectory, the directory would always appear at the end  
of a TIFF file, after the pixels, and reading partial TIFF files would  
be impossible.  Some control of data order in the file IS useful,  
namely: does the directory appear before or after the pixels?

Other situations where it's useful to have the directory first: if a  
file is being streamed in, you might want to inspect the directory and  
cancel the streaming.  And for very large files (I currently work with  
TIFFs up to 4 gigabytes, and soon, larger) it's nice to maximize  
performance and minimize seek times by putting directories,  
thumbnails, and other header-like information at the beginning of a  
file.  That's also the order in which most of the rest of the world  
writes their TIFF files.

PS: If we're interested in distant history, I worked with Sam Leffler  
at Pixar in 1986 and he and I wrote the Pixar Software Standards  
document together.


Returning to my code:

I wonder if others have attempted to write two directories (IFDs)  
using TIFFCheckpointDirectory.  Anyone got pointers to code that does  
this?  Am I using TIFFSetDirectory properly?

My current hypothesis: TIFFCheckpointDirectory works fine if you're  
writing only one directory, but it's buggy when there are multiple  
directories.

I tested further and it seems that my program, when run with "thumb - 
nocheckpoint", yields a TIFF that "exiftool -hexdump" can parse  
properly even though the directories follow the pixels.  I don't know  
if other TIFF-reading software can parse it properly, however.

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