Received: from mailgate002.isp.belgacom.be (mailgate002.isp.belgacom.be [195.238.6.87])
	by maildelivery017.isp.belgacom.be (Postfix) with ESMTP id 65A35C062
	for <joris.at.lebbeke@skynet.be>; Thu,  5 Jul 2007 12:18:16 +0200 (CEST)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 05 Jul 2007 12:18:15 +0200
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 l65A8C0X006200;
	Thu, 5 Jul 2007 06:08:19 -0400
Received: from mailhost.informatix.co.uk (informatixdsl.claranet.co.uk
	[80.168.136.49])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l65A8920006197
	for <tiff@lists.maptools.org>; Thu, 5 Jul 2007 06:08:09 -0400
Received: from [10.4.0.4] (unverified [127.0.0.1]) by mailhost.informatix.co.uk
	(Rockliffe SMTPRA 7.0.3) with ESMTP id
	<B0001012957@mailhost.informatix.co.uk> for
	<tiff@lists.maptools.org>; Thu, 5 Jul 2007 11:08:07 +0100
Message-ID: <468CC293.9010707@informatix.co.uk>
Date: Thu, 05 Jul 2007 11:06:11 +0100
From: John Aldridge <john.aldridge@informatix.co.uk>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: tiff@lists.maptools.org
Subject: Re: [Tiff] BigTIFF extension
References: <200707041802.l64I2mau023841@duke.maptools.org><B3C7254C-81E3-4CBA-AD9C-D5796B4F5E9E@owl.phy.queensu.ca><73D53923-6DFF-43AB-A582-7AEAED4EFD07@smartgames.ca>	<8054F84A-7599-4713-9AD6-FD1584EB2214@owl.phy.queensu.ca>
	<002101c7be7d$3b02fef0$0201a8c0@AWareCore2Duo>
In-Reply-To: <002101c7be7d$3b02fef0$0201a8c0@AWareCore2Duo>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.00002550
X-MSP-STORE: Thu, 05 Jul 2007 12:18:16 +0200
Status:   

Joris wrote:
> 1) BigTIFF is TIFF.

No it's not :-) It's not in the TIFF specification

   http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

which also claims that TIFF is an Adobe trademark, so presumably they 
are the people entitled to specify it!

However, forget what we call it. I think the following statements are 
uncontentious


a) No BigTIFF file will be readable by any existing TIFF processing code.

Many such applications will be in use in the field for many years. Even 
if the application is updated by the authors, many users will not want 
to upgrade to the latest version. I still use PaintShop Pro 7, for 
example, because the improvements in later versions are not worth the 
upgrade cost to me.


b) BigTIFF files will be readable by pretty much any application which 
is recompiled against an up to date version of libtiff (or presumably 
pretty much any other TIFF library, I would hope).

We have a reasonable expectation, then, that the distinction between the 
two formats will eventually become insignificant.


c) TIFF has always had a problem with applications supporting only a 
subset of its possible format options.

The BigTIFF format is similar to this in many ways, but with the 
following differences of degree:

* The error messages issued by non-supporting applications are less 
helpful (something like "not a TIFF file", rather than "unsupported 
compression type").

* BigTIFF support is easier to add to existing applications (it's all in 
the library) rather than, say, tile support which typically requires 
application code change.


d) The image/tiff MIME Sub-type Registration (RFC 2302) refers 
explicitly to TIFF6 and "all of the profiles and extensions that build 
on (it)". Unless IANA amend this to include BigTIFF data, it'll be hard 
for web servers to set this properly unless the files have a different 
suffix.


So it comes down to a balancing act: is it better to improve the user 
experience for people with non-BigTIFF supporting applications, or to 
avoid the possible confusion caused by a separate type suffix when in 
the long term we hope that the vast majority of applications won't need 
to distinguish them.

I guess it depends on your take on how long "long term" is, and how vast 
"vast majority"!
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
