Return-Path: <tiff-admin@remotesensing.org>
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.3.90])
        by mailst006.isp.belgacom.be (8.12.9/8.12.9/Skynet-MAILSTORE-2.14) with ESMTP id i3QCpAa6022640
        for <joris.at.lebbeke@skynet.be>; Mon, 26 Apr 2004 14:51:10 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.44])
        by inmx012.isp.belgacom.be (8.12.9/8.12.9/Skynet-IN-2.32) with ESMTP id i3QCp1mR024147
        for <joris.at.lebbeke@skynet.be>; Mon, 26 Apr 2004 14:51:02 +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 i3QCo6n26487;
	Mon, 26 Apr 2004 08:50:06 -0400
Received: from [207.180.30.181] (mta.ecrm.com [207.180.30.181])
	by yoda.imagelinks.com (8.11.6/8.11.6) with SMTP id i3QCnGn26461
	for <tiff@remotesensing.org>; Mon, 26 Apr 2004 08:49:16 -0400
Received: from mta.ecrm.com by [207.180.30.181]
          via smtpd (for [208.24.120.58] [208.24.120.58]) with SMTP; Mon, 26 Apr 2004 08:49:07 -0400
Received: from mail.ecrm.com (mail.ecrm.com [192.168.10.75])
	by mta.ecrm.com (Switch-2.2.8/Switch-2.2.4) with ESMTP id W3QC2DHD00000850;
	Mon, 26 Apr 2004 08:49:17 -0400
Message-id: <fc.0064b57b00efecda3b9aca00f733b2b0.efeed8@ecrm.com>
Subject: Re: [Tiff] Large TIFF files: explicitly different format
To: john.aldridge@informatix.co.uk
Cc: tiff@remotesensing.org
From: "Dan Smith" <d_smith@ecrm.com>
References: <Pine.GSO.4.44.0404221641250.11901-100000@scooby.simplesystems.org>
 <p0521061cbcadf0a4cb7d@[153.32.48.223]>
 <001e01c428b9$962b7df0$837988d9@dfgrrxsknr4e>
 <p0521061dbcadf8729fcf@[153.32.48.223]>
 <40890FE4.7080302@informatix.co.uk>
 <000f01c42934$afb6d690$2a57f051@dfgrrxsknr4e>
 <408CBA8B.B98D90BB@oce.nl>
 <002301c42b75$0b14ff70$e1b588d9@dfgrrxsknr4e>
 <408CED3A.31E6D7B5@oce.nl>
 <001701c42b81$aad61970$6f7a88d9@dfgrrxsknr4e>
 <408CFAF7.1070805@informatix.co.uk>
In-Reply-To: <408CFAF7.1070805@informatix.co.uk>
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MessageInspectorSig: 68bbd640433cc81cf8ceb7c427494049
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: Mon, 26 Apr 2004 08:53:20 -0400
X-UIDL: e7a8c4777da88e10038d06a3f21024d0

I'm usually on the side of utter, total, complete, effortless, seamless
compatibility. But in this particular case, I think that an explicitly
different format might work. 

By an "explicitly different format," I mean one with some different name (BTIFF
or BIGTIFF or TIFF2004 or TIFF Plus or TIFF Extreme...), and one that the user
must _consciously_ select when specifying the file format. When such a file is
sent from one user to another, both the sender and recipient are _consciously_
aware that it is a big TIFF file, not a classic TIFF file.

Here's how I envision the transition/migration process occurring, and why I
don't think seamless compatibility is needed. 

In most cases, people will need big TIFF for work which they perceive as being
_different from_ they are now doing. They will be aware that they are doing
something _new_ (e.g. outputting to a new platesetter). 

The only people who _need_ to use big TIFF are people that actually are using
multi-gigabyte-size image files. In many cases these files will be generated
and consumed locally, e.g. between closely related pieces of software; for
example, we have a Harlequin plugin that generates TIFF and we have a software
product that consumes the TIFF we generate, and if we were to implement big
TIFF it would be transparent to the user as they'd be changed at the same time,
and the files are not used except to move images between these two pieces of
software. 

When big TIFFs are exchanged if a recipient has software that cannot accept big
TIFF files, it will be because they have an output device that cannot output
such files. Conversely, if both parties are used to working with multi-gigabyte
files, they will probably have software that is big-TIFF savvy. 

It is _relatively_ unlikely that there will be _serious_ issues with, say,
people accidentally sending 2 megapixel digital camera snapshots in big TIFF
format to people who will be unable to read it.

Meanwhile, IF the big TIFF format is separate from _but logically similar to_
regular TIFF, and perhaps also to Adobe's big image format, one might expect
that code and adoption of big-TIFF capability might be relatively easy and
relatively rapid, at least within the corpus of software that is being actively
maintained. And if they are logically similar, it is likely that they will be
maintained in parallel, and that many portions of the code will still be common
(and can be evolved or bug-fixed at the same time). This means that support for
classic TIFF will not end suddenly when big TIFF is introduced.

Conversely, the need to handle small TIFF files will continue for decades;
thus, if the standard build of LIBTIFF includes support for both big and
standard TIFF, I think it is very unlikely that products using LIBTIFF that
support standard TIFF now would drop that support when they add support for big
TIFF.

This is more in the nature of "thinking out loud" then a carefully reasoned
piece of advocacy. If there were a brilliant way of retaining total
compatibility and automagic conversions-on-the-fly-when-needed so that to the
end-user, TIFF would be TIFF, that would be great; but I'm saying that
explicitly breaking compatibility at the end-user level might not be so bad IF
the formats were logically similar AND THEREFORE support for big TIFF was
smooth, easy, and fast at the developer level. The typical end-user might see a
new "use Big TIFF format never/when needed/always"  checkbox appear in their
software long before they needed to use it.

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