Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx015.isp.belgacom.be (inmx015.isp.belgacom.be [195.238.2.218])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i94J0aca028617
        for <joris.at.lebbeke@skynet.be>; Mon, 4 Oct 2004 21:00:36 +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 inmx015.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i94J0E9X030516
        for <joris.at.lebbeke@skynet.be>; Mon, 4 Oct 2004 21:00:19 +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 2C00D35294C; Mon,  4 Oct 2004 14:59:40 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from hog3.hogserve1.com (hog3.hogserve1.com [217.199.182.233])
	by xserve.flids.com (Postfix) with ESMTP id 64B903528CE
	for <tiff@remotesensing.org>; Mon,  4 Oct 2004 14:59:26 -0400 (EDT)
Received: from 81-178-2-108.dsl.pipex.com ([81.178.2.108] helo=PLATO)
	by hog3.hogserve1.com with smtp (Exim 4.34)
	id 1CEY3G-0004qE-9N; Mon, 04 Oct 2004 19:59:14 +0100
Message-ID: <062901c4aa44$457ec350$0200a8c0@PLATO>
From: "Andy Cave" <andy.cave@hamillroad.com>
To: "Tiff mailing list" <tiff@remotesensing.org>,
        "Bill Bither" <bill.bither@atalasoft.com>,
        "Joris" <joris.at.lebbeke@skynet.be>
References: <2A7F84B7BBB1CC4F88A9AD71142B91C8032EF6@ATALADC1.atalasoft.lcl>
	<000701c4aa42$7cced630$727b88d9@dfgrrxsknr4e>
Subject: Re: [Tiff] Re: BigTIFF extension issue
Date: Mon, 4 Oct 2004 19:59:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hog3.hogserve1.com
X-AntiAbuse: Original Domain - remotesensing.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hamillroad.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: 
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: a2c68f685bfc65d5b81ba7cbd730da6c

Hi All.

Here's my crunch argument for calling it .tiff.

As a good programmer, I should write a good library. My library should write 
a dummy header that could be either little tiff or big tiff. It should then 
write the possibly unknown sized compressed data. If the file size ends up 
being too big, then it should patch it up as a big tiff file. If the file 
size ends up being small enough, it should patch it up as a small tiff file. 
In the case of patching it up as small tiff, there would be a small amount 
of space wasted - so what.

The big tiff file format should also introduce a new header / dict tag which 
is EXPLICITLY designed to allow for space that can be used later on. If I 
open a small tiff file, and append some data which then makes it a big tiff 
file, IF the file is only small tiff and the library is small tiff lib 
(2.5.7,...), it will fail. If the library is big tiff compatible, and the 
image file has this extra header / dict tag, then this extra header / dict 
tag can be used to 'expand/convert' the existing date from small tiff to big 
tiff.

Now think what this means. All files produced that are less than 2/4G called 
.tif can be processed by existing applications. They can be expanded and 
remain as small tiff. They can be expanded and converted to big tiff. Nice 
and backwards compatible. Any files produced that are (end up being) more 
than 2/4G probably could not be processed by existing applications anyway, 
as these apps probably have in them inherently the 2/4G limit that TIFF 
files have anyway.

So, as part of the big tiff spec, we REQUIRE that this extra header info and 
extra dict tags be there that allows a big tiff conforming file to expand.

Customers keep their existing extension. Bigtif files that are written that 
are small NEVER have a problem with existing libraries, including 2.5.7, 
3.0... of tiff. A bigtif library that reads a small tiff file, that does NOT 
contain these additions, is NOT allowed to append to that file and make it a 
bigtif file.

Everything works.

QED. End of discussion.

_andy.


_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
