Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.3.90])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i8GJCAle022791
        for <joris.at.lebbeke@skynet.be>; Thu, 16 Sep 2004 21:12:11 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx012.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i8GJBqCY027622
        for <joris.at.lebbeke@skynet.be>; Thu, 16 Sep 2004 21:11:54 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 0ABE82F06D8; Thu, 16 Sep 2004 15:11:34 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx005.isp.belgacom.be (outmx005.isp.belgacom.be
	[195.238.2.102])
	by xserve.flids.com (Postfix) with ESMTP id 513702F06B5
	for <tiff@remotesensing.org>; Thu, 16 Sep 2004 15:11:31 -0400 (EDT)
Received: from outmx005.isp.belgacom.be (localhost [127.0.0.1])
	by outmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id i8GJBNQ9015002
	for <tiff@remotesensing.org>; Thu, 16 Sep 2004 21:11:23 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (195.37-200-80.adsl.skynet.be [80.200.37.195])
	by outmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id i8GJBJL5014969; Thu, 16 Sep 2004 21:11:19 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <001c01c49c21$2bf33730$c325c850@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Tiff mailing list" <tiff@remotesensing.org>
Date: Thu, 16 Sep 2004 21:12:54 +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.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Cc: 
Subject: [Tiff] BigTIFF Tag Value Count issue
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 766d4f6c70e96f2647f6c07810480f44

People,

Chris and I have been discussing BigTIFF, as the current Wiki specifies, and
we've come to a subject that we both would like more comments and opinions on.

To eliminate chances of misunderstandings, please allow me to specify the full
tag structure and mark the member in question.

Offset - Datatype - Value
--------------------------
0 - Word - Tag identifying code
2 - Word - Datatype of tag data
4 - Unsigned Long - Number of values
8 - 4 bytes - Tag data or offset

For a more clear HTML table view on this and the two even more highest level
structures, should you need a quick reminder, see
http://www.awaresystems.be/imaging/tiff/faq.html#q3.

The current Wiki specifies there is only one difference between Classic TIFF and
BigTIFF, as far as this structure is concerned, and that is, of course, that
fourth, last member, the data/offset, that is 8 bytes wide in BigTIFF.

The thing that is now up for debate is the third member, the 'Count' member, the
member that specifies the number of values. We are unsure as to whether we
really want to keep it 4 bytes, or extend this member to 8 bytes, as well.

Argument pro 4 bytes is that this keeps all 8 byte values in the TIFF file
perfectly aligned on multiples of 8.

This may be a poor argument, since alignment inside a file really might not be
that important.

Argument pro 8 bytes is that tags may be private, meaning tag value is
essentially opaque to the TIFF specification, meaning it's 'anything' as far as
TIFF goes, meaning that we might want to acknowledge that it might need to grow
beyond the 4 gig boundary. After all, we're having TIFF itself grow beyond that
boundary, for good reason. 'Do upon others as you would like others to do upon
yourself'. Or something. Academically speaking, it feels a bit weird the BigTIFF
itself wouldn't fit in the space that BigTIFF reserves for the opaque
'anything'.

Not that there's much of a chance for the actual need, in practice, and that's
why this may be poor argument too. I don't think we're ever going to see any tag
grow beyond 4 gig, and we most probably will never see a TIFF tag that is a
TIFF, since we've got the SubIFD scheme that covers this need.

Another thing to consider is what happens if we discard the need for 8byte
values to be aligned... suddenly, the rationale behind having the 'number of
tags' first member of each IFD grow to 8 bytes wide also becomes invalid, and we
need to rethink that as well.

Another thing that may be 'spirit' related is the Tile/Strip ByteCounts... The
current Wiki allows these to be specified with 8byte wide values. It seems that
even though they are not related, they are somehow related, as the idea of
having a single strip or tile growing beyond 4 gig is just as wild - or as
carefull - as the idea of a single tag growing beyond 4 gig in size.

What do you all think?




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@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
