Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas030.isp.belgacom.be (localhost [127.0.0.1])
        by inav015.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k352sekD007818
        for <joris.at.lebbeke@skynet.be>; Wed, 5 Apr 2006 04:54:40 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx016.isp.belgacom.be (inmx016.isp.belgacom.be [195.238.4.219])
        by inas030.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k352sXQ3012691
        for <joris.at.lebbeke@skynet.be>; Wed, 5 Apr 2006 04:54:37 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx016.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k352sRN3001903
        for <joris.at.lebbeke@skynet.be>; Wed, 5 Apr 2006 04:54:27 +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 k352Nn1P012543;
	Tue, 4 Apr 2006 22:24:02 -0400
Received: from outmx020.isp.belgacom.be (outmx020.isp.belgacom.be
	[195.238.4.201])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k352Nibo012493
	for <tiff@lists.maptools.org>; Tue, 4 Apr 2006 22:23:44 -0400
Received: from outmx020.isp.belgacom.be (localhost [127.0.0.1])
	by outmx020.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with ESMTP id k352Nek2015423
	for <tiff@lists.maptools.org>; Wed, 5 Apr 2006 04:23:40 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (76-160.245.81.adsl.skynet.be [81.245.160.76])
	by outmx020.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with SMTP id k352Nc0r015414; Wed, 5 Apr 2006 04:23:38 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <002a01c65858$4072f5c0$4ca0f551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>
References: <C058342F.2AA25%ccox@adobe.com>
	<000b01c65832$94a1ab30$0eb8f551@dfgrrxsknr4e>
	<Pine.SOC.4.60.0604042049010.26690@blade.simplesystems.org>
Subject: Re: [Tiff] BigTIFF Suggestion
Date: Wed, 5 Apr 2006 04:22:52 +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.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Cc: TIFF <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.00001528
X-MSP-STORE: Wed, 05 Apr 2006 04:54:43 +0200
Status:   

Bob,

Bob Friesenhahn wrote:
> Playing devil's advocate for a moment, it is worth pointing out that
> multi-frame TIFFs are a convenient way to build big TIFFs and that one
> of the strengths of BigTIFF is that it can handle huge files.
> Perhaps some additional adaptations to the TIFF format may make it
> more useful for huge files.  If so, they should be considered now
> before there is an implementation in use.

Devil's advocate is my favorite game...

Of course, we would need to respect the basic properties of TIFF. For
example, I am much opposed to anything that seems redundant, in the
higher level TIFF structures. In fact, I'd like to keep on to the tree
hierarchy very strictly...

The single thing that remains, to allow faster access to not just the
last but any page, is to, optionally, store 'page/frame groups' or
whatever you would call them in the highest level linked list. Such a
group would be a very basic IFD, with likely not much more then two
tags:
- a page count tag, stating the number of pages in this group
- a page tag, stating the offset to the first page IFD in the group.

For example, to allow fast and easy access to all of 1000 pages, one
could have an upper level linked list of 10 IFDs, that all are 'group'
IFDs, and all are the starting point of a second-level linked list of
100 image IFDs.

Going one step further, the scheme could be extended. The group IFDs
themselves, may be the start of another linked list of groups... forming
a sort-off page hash.

In effect, this would
a) not break the IFD tree scheme
b) not contain anything redundant
c) not contain any data anywhere that transcends its logical scope
d) allow very fast access to any page

Of course, the number of pages in a group and such, should remain
totally up to the writer to decide. Otherwise the need for reordering
and such may arise on 'page delete' operations, and that is not
desirable. So, stupid writers would still be able to choose the easy way
out and write a single list of 10.000 IFDs.

Strictly playing devil's advocate, of course. I do think it is
worthwhile to play that game, seriously, because, as you say, BigTIFF is
big.

> Of course there are other formats which are easier to extend such as
> MNG, ImageMagick's MIFF format (extension via pure concatenation),
> PDF, and even QuickTime.  Those formats are nothing like TIFF.

Voila, my point exactly.


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@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
