Return-Path: <tiff-admin@remotesensing.org>
Received: from inmx016.isp.belgacom.be (inmx016.isp.belgacom.be [195.238.2.219])
        by mailst006.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i5A7fB0o018936
        for <joris.at.lebbeke@skynet.be>; Thu, 10 Jun 2004 09:41:11 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.44])
        by inmx016.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i5A7elon023875
        for <joris.at.lebbeke@skynet.be>; Thu, 10 Jun 2004 09:40:49 +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 i5A7cUV29085;
	Thu, 10 Jun 2004 03:38:30 -0400
Received: from smtp01.oce.nl (smtp01.oce.nl [134.188.1.25])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i5A7baV29058
	for <tiff@remotesensing.org>; Thu, 10 Jun 2004 03:37:37 -0400
Received: from smtp05 (smtp05.oce.nl [134.188.1.26])
	by smtp01.oce.nl (8.12.8p1/8.12.8) with ESMTP id i5A7bKKe000324;
	Thu, 10 Jun 2004 09:37:20 +0200 (MEST)
Received: from smtp-venlo.oce.nl (localhost [127.0.0.1])
	by smtp05 (8.12.8p1/8.12.8) with ESMTP id i5A7bJN5003449;
	Thu, 10 Jun 2004 09:37:19 +0200 (MEST)
Received: from smtp03.oce.nl (smtp03.oce.nl [134.188.150.26])
	by smtp-venlo.oce.nl (8.12.8p1/8.12.8) with ESMTP id i5A7bGkQ003189;
	Thu, 10 Jun 2004 09:37:17 +0200 (MEST)
Received: from oce.nl (localhost [127.0.0.1])
	by smtp03.oce.nl (8.12.8p1/8.12.8) with ESMTP id i5A7bFie005206;
	Thu, 10 Jun 2004 09:37:16 +0200 (MEST)
Message-ID: <40C80FAB.96062E1B@oce.nl>
From: Rob van den Tillaart <rvdt@oce.nl>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD   (WinNT; I)
X-Accept-Language: en,nl
MIME-Version: 1.0
To: Steve Carlsen <scarlsen@adobe.com>
CC: tiff@remotesensing.org
Subject: Re: [Tiff] Re: large TIFF - two alternatives
References: <p06020407bcdaeefbd542@[153.32.220.138]> <p06020405bced16b95f0c@[153.32.220.138]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Filter-Version: 1.12a-oce (smtp-venlo)
X-Spam-Scanner: E-mail has been checked
X-Spam-Scanner-Check: not spam (whitelisted), SpamAssassin (score=-6.3,
	required 5, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50,
	QUOTED_EMAIL_TEXT -0.38, REFERENCES -0.00, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_MOZILLA_XM 0.00)
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: Thu, 10 Jun 2004 09:37:15 +0200
X-UIDL: 188e0ce2508e5b067e9c27ef7ca5d4d6


Steve Carlsen wrote:
> 
> At 18:15 -0700 5/26/04, Steve Carlsen wrote:
> 
> It seems like the prevailing opinion is for making "Large TIFF" be
> mostly just like existing TIFF except for supporting 8-byte addresses.
> 
> Making the "Alternative 1" proposal a bit more concrete, then, and
> adding some 8-byte alignment language and a hook for future expansion:
> 
> ============================= 8-Byte TIFF =======================
> 
> A. The ID, in header bytes 2-3, formerly decimal 42, now changes to
> 0x4242.
>  ( I really like the '42', and this seems like a nice way to have my
> cake and eat it, too.)

0x42 is a 'B' so 0x4242 = "BB" (BIG BLOB? :)

> B. Header bytes 4-5 contain the decimal number 8. (If there is some
> other number here, a reader should give up.)
>   (to provide a nice way to move to 16-byte pointers some day.)'

You mean 0x0008; leaves room to grow to 0x1000 (4096) byte pointers
giving an address space of 2**32768 ~ 10**9864 bytes. You're thinking
really big.

> C. Header bytes 6-7 are reserved and must be zero. (If they're not, a
> reader should give up.)
I think the reader should notice but can proceed at own risk.

> D. Header bytes 8-15 contain the 8-byte offset to the 0th IFD.
> 
> E. Value/Offset fields are 8 bytes long, and take up bytes 8-15 in an
> IFD entry.
>   (If the value is <= 8 bytes, it must be stored in the field.)
>   (All values must begin at an 8-byte-aligned address.)
> 
> F. 8-byte offset to the Next_IFD, at the end of an IFD.
> 
> G. to keep IFD entries 8-byte-aligned, we begin with an 8-byte
> (instead of 2-byte) count of the number of directory entries.
> 
> H. add TIFFTypes of LONG8 (= 13), an 8 byte (unsigned) int, and SLONG8
> (= 14).

please also add:
- RATIONAL8     LONG8/ LONG8   	(16 bytes)
- COMPLEX       LONG8, LONG8	(16 bytes)

> I. StripOffsets and TileOffsets and ByteCounts can be LONG8.
I would like to make a must of that. keep things 8 bytes aligned.

> J.The extension is ".tf8", and the format is called "8-Byte TIFF".
>
Breaking the file-extention is imho not alternative 1. 
The file extention should still be .tif or .tiff

> Otherwise, it's just like "original TIFF." ("TIFF Classic?")
> 
> ===================================================================
> 
> Are we close to general agreement? 
Guess so,

> Am I missing something?
See above.


I know that there does not exist an average TIFF file but a tickling
question 
is how much an average (<2GB) tiff file would increase by using this
scheme.

IFD entry is 		now		new
	tag		2		8
	type		2		8
	count n		4		8
	value/offset	4 		8
	--------------------------------------------
	total		8 + n x 4	24 + n x 8

The size of an IFD will grow by a factor 32/12 < 3. (when no tiles are
used) 
but when tiles are used the growth factor will be closer to 2. (due to 8
byte alignment).


> Regards,
> Steve Carlsen

Regards,
rob.
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://remotesensing.org/mailman/listinfo/tiff
