AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.04.26 12:53 "Re: [Tiff] Large TIFF files: explicitly different format", by Dan Smith
2004.04.26 13:16 "Re: [Tiff] Large TIFF files: explicitly different format", by Joris
2004.04.26 17:10 "Re: [Tiff] Large TIFF files: explicitly different format", by Chris Cox

2004.04.26 12:53 "Re: [Tiff] Large TIFF files: explicitly different format", by Dan Smith

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.