2007.07.06 12:36 "Re: [Tiff] BigTIFF extension", by Gary McGath

I put out the arguments for and against keeping the same file extension a few years ago. They're getting rediscovered and rehashed now. But if we (Adobe) just try to legislate the decision without support from the user and developer community, it won't get very far.

So, I'm just trying to guide the discussion and see what you come up with.

To make it clear what species of dog I have in this fight: I'm looking at the issue primarily from an archiving standpoint. If people a hundred years from now dig through the metaphorical ruins and find a file and a copy of the relevant specification, will they be able to reconstruct its presentation?

If BigTIFF is incorporated into the official spec as TIFF 7.0 _and_ it's widely disseminated enough that it effectively supersedes TIFF 6.0, then that's accomplished; otherwise they'll see something which looks sorta like TIFF, and they might or might not be able to reverse engineer the differences.

What I don't what to see is two different specs which are both called TIFF, even if one incorporates the other by reference. That's where I see things heading, and that's a recipe for long-term confusion.

There's also the risk that BigTIFF won't catch on; in that case, the few BigTIFF documents that are created will stand a better chance of being recognized if they have a distinct extension or MIME type, spurring the archaeologists to more research.

If BigTIFF had been conceived from the beginning as a revision rather than a variant of TIFF, I suspect some things would have been done differently. For example, the new header might have specified whether to use classic or expanded format for the IFD offsets, the tag counts, and the number of values within a tag respectively, since it might not be necessary to incur the extra overhead of all three. The existing proposal is more of a clean break from TIFF, which is another argument for considering it a distinct format.

For that matter, if TIFF is being revised, it would be very desirable to clean up some of the ambiguities in the 6.0 spec, such as when a practice is required and when it's just recommended.

--
Gary McGath
Digital Library Software Engineer
Harvard University Library Office for Information Systems
http://hul.harvard.edu/~gary/index.html