Return-Path: <tiff-admin@remotesensing.org>
Received: from inmx010.isp.belgacom.be (inmx010.isp.belgacom.be [195.238.2.73])
        by mailst006.isp.belgacom.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.14) with ESMTP id i4R1JFVc000734
        for <joris.at.lebbeke@skynet.be>; Thu, 27 May 2004 03:19:15 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.44])
        by inmx010.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id i4R1J8XB000853
        for <joris.at.lebbeke@skynet.be>; Thu, 27 May 2004 03:19:09 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com (localhost.localdomain [127.0.0.1])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i4R1HOx18997;
	Wed, 26 May 2004 21:17:24 -0400
Received: from smtp-relay-8.adobe.com (smtp-relay-8.adobe.com [192.150.22.8])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i4R1G3x18926
	for <tiff@remotesensing.org>; Wed, 26 May 2004 21:16:03 -0400
Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51])
	by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i4R1Fe6P000444
	for <tiff@remotesensing.org>; Wed, 26 May 2004 18:15:46 -0700 (PDT)
Received: from seaclus2 (seaclus2.sea.adobe.com [153.32.250.104])
	by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i4R1FS3m019316
	for <tiff@remotesensing.org>; Wed, 26 May 2004 18:15:34 -0700 (PDT)
Received: from [153.32.220.138] (foobird.sea.adobe.com [153.32.220.138])
 by mailsea.sea.adobe.com
 (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003))
 with ESMTP id <0HYC00DDMM5W94@mailsea.sea.adobe.com> for
 tiff@remotesensing.org; Wed, 26 May 2004 18:15:33 -0700 (PDT)
From: Steve Carlsen <scarlsen@adobe.com>
X-Sender: scarlsen@mailsea.sea.adobe.com
To: tiff@remotesensing.org
Message-id: <p06020407bcdaeefbd542@[153.32.220.138]>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_AWBWaEe9JbBTPlVic9WIjQ)"
Subject: [Tiff] large TIFF - two alternatives
Sender: tiff-admin@remotesensing.org
Errors-To: tiff-admin@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Post: <mailto:tiff@remotesensing.org>
List-Subscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
List-Id: TIFF and libtiff discussion <tiff.remotesensing.org>
List-Unsubscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://remotesensing.org/pipermail/tiff/>
Date: Wed, 26 May 2004 18:15:27 -0700
X-UIDL: 20bf3a161ee75ef92d1a50336c2bc7c9


--Boundary_(ID_AWBWaEe9JbBTPlVic9WIjQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Greetings all,

I haven't been involved in TIFF for a very long time, but I've been 
talking to Chris Cox about the subject of "Large TIFF", and would 
like to run a couple of alternatives by this group.

The first alternative is, I think, the smallest number of changes 
possible such that the result cleanly supports 8-byte addresses.

The second alternative is the way I would design TIFF if I were doing 
it over again today, taking advantage of the fact that no old TIFF 
readers will be able to read "Large TIFF" files anyway, even with the 
minimal approach.

The second alternative is more general, more flexible, easier to 
debug, supports layers, and simplifies a number of things.

I don't _really_ expect to convince everyone that Alternative 2 is 
worth the new code that it would require (not that any of it is 
difficult); but I thought I should bring it up because if we're ever 
going to move to a a more powerful version of the 'old TIFF', there 
will never be a better opportunity than now.

- SteveC



Alternative 1:  Minimal changes for TIFF to support 8-byte addresses
-----------------------------------------------------------------------------------------------------

a. ID = 43 (or maybe 0x4242?)
b. 8-byte offset to 0th IFD
c. Value/Offset fields are 8 bytes
d. 8-byte offset to the next IFD (does anyone use this?)
e. add TIFFType of LONG8, an 8 byte (unsigned) int
f. StripOffsets and TileOffsets and ByteCounts can be LONG8


Alternative 2:  A more modern and general approach
--------------------------------------------------------------------
(in the following, any power of two can be used instead of 8)

a. ID = the string "TIFF2"
b. 8-byte pointer to 0th IFD/Dictionary
c. Value/pointer  fields are 8 (2**x) bytes
d. 8-byte child pointers
e. add an 8-byte TIFF integer type, but it's rarely used explicitly
f. StripOffsets and TileOffsets and ByteCounts are 8 bytes

g. support for  4 or 8 or 16 or ... 2**X byte addresses (header tells 
which one you're using)
h. use of ASCII tags/keys  instead of binary ones
i. most values are ASCII strings, too: integers, floating point 
numbers, enums, yielding fewer data types
j. Dictionaries (IFDs) can be really large.
k. Cleaner hierarchical structure, with explicit inheritance from 
parents. top-level dictionary contains metadata only; it does not 
point to image data.
l. Explicit support for layers
m. All data is planar (though it can be interleaved by row or tile)
n. So there are 4 levels to the hierarchy: Root, Image, Layer, and 
Channel. Only Channel dictionaries point to image data.
o. Multi-byte numeric values are always big-endian, not that it 
matters very often in this more string-oriented approach.
p. All other rules are normal TIFF rules.

--Boundary_(ID_AWBWaEe9JbBTPlVic9WIjQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>large TIFF - two alternatives</title></head><body>
<div><font face="Helvetica" color="#000000">Greetings
all,</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">I haven't been involved in
TIFF for a very long time, but I've been talking to Chris Cox about
the subject of &quot;Large TIFF&quot;, and would like to run a couple
of alternatives by this group.</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">The first alternative is,
I think, the smallest number of changes possible such that the result
cleanly supports 8-byte addresses.</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">The second alternative is
the way I would design TIFF if I were doing it over again today,
taking advantage of the fact that no old TIFF readers will be able to
read &quot;Large TIFF&quot; files anyway, even with the minimal
approach.</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">The second alternative is
more general, more flexible, easier to debug, supports layers, and
simplifies a number of things.</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">I don't _really_ expect to
convince everyone that Alternative 2 is worth the new code that it
would require (not that any of it is difficult); but I thought I
should bring it up because if we're ever going to move to a a more
powerful version of the 'old TIFF', there will never be a better
opportunity than now.</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">- SteveC</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">Alternative 1:&nbsp;
Minimal changes for TIFF to support 8-byte addresses</font></div>
<div><font face="Helvetica"
color="#000000"
>--------------------------------------------------------------------<span
></span>---------------------------------</font><br>
<font face="Helvetica" color="#000000"></font></div>
<div><font face="Helvetica" color="#000000">a. ID = 43 (or maybe
0x4242?)</font></div>
<div><font face="Helvetica" color="#000000">b. 8-byte offset to 0th
IFD<br>
c. Value/Offset fields are 8 bytes<br>
d. 8-byte offset to the next IFD (does anyone use this?)<br>
e. add TIFFType of LONG8, an 8 byte (unsigned) int<br>
f. StripOffsets and TileOffsets and ByteCounts can be LONG8</font><br>
<font face="Helvetica" color="#000000"></font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">Alternative 2:&nbsp; A
more modern and general approach</font></div>
<div><font face="Helvetica"
color="#000000"
>--------------------------------------------------------------------</font
></div>
<div><font face="Helvetica" color="#000000">(in the following, any
power of two can be used instead of 8)</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">a. ID = the string
&quot;TIFF2&quot;<br>
b. 8-byte pointer to 0th IFD/Dictionary<br>
c. Value/pointer&nbsp; fields are 8 (2**x) bytes<br>
d. 8-byte child pointers<br>
e. add an 8-byte TIFF integer type, but it's rarely used
explicitly</font></div>
<div><font face="Helvetica" color="#000000">f. StripOffsets and
TileOffsets and ByteCounts are 8 bytes</font></div>
<div><font face="Helvetica" color="#000000"><br></font></div>
<div><font face="Helvetica" color="#000000">g. support for&nbsp; 4 or
8 or 16 or ... 2**X byte addresses (header tells which one you're
using)</font></div>
<div><font face="Helvetica" color="#000000">h. use of ASCII tags/keys&nbsp;
instead of binary ones<br>
i. most values are ASCII strings, too: integers, floating point
numbers, enums, yielding fewer data types<br>
j. Dictionaries (IFDs) can be really large.<br>
k. Cleaner hierarchical structure, with explicit inheritance from
parents. top-level dictionary contains metadata only; it does not
point to image data.<br>
l. Explicit support for layers<br>
m. All data is planar (though it can be interleaved by row or
tile)<br>
n. So there are 4 levels to the hierarchy: Root, Image, Layer, and
Channel. Only Channel dictionaries point to image data.</font></div>
<div><font face="Helvetica" color="#000000">o. Multi-byte numeric
values are always big-endian, not that it matters very often in this
more string-oriented approach.</font></div>
<div><font face="Helvetica" color="#000000">p. All other rules are
normal TIFF rules.</font></div>
</body>
</html>

--Boundary_(ID_AWBWaEe9JbBTPlVic9WIjQ)--
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://remotesensing.org/mailman/listinfo/tiff
