2007.07.03 18:37 "[Tiff] BigTIFF extension?", by Phil Harvey

2007.07.09 14:10 "Re: [Tiff] BigTIFF extension", by Joris Van Damme


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.

Though we seem to arive at different conclusions, our way of thinking is not much different. I too, look at it from this archiving standpoint. I'm a strong believer in open formats, for the simple reason that I believe a user's data should be regard his own property to move into and out of applications as he sees fit. I too, have this notion of 'digital dark age', and I ask myself constantly if our grandchildren will be able to view our data.

I think we should work from the assumption that we'll succeed in having BigTIFF incorporated in a TIFF 7.0, or at the very least that we'll succeed in having some official form of the proposal as official specification supplement. If we don't work from that assumption and towards that goal, our work is not of much value.

Sofar, the official owner of the TIFF format has neither officially accepted, nor officially rejected BigTIFF. Let's wait and see, and help out all we can, and push things as hard as we can, and assume that the owner will do the responsible thing.

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.

You'd be making 2*2*2 = 8 version of the most basic structure, if I understand we're you're heading. You'd furthermore cause considerable complication for editing, as editing is mostly appending new blocks and updating pointers to the blocks and may change required bitdepths of those pointers as the file grows. I think our current accepted proposal is much cleaner and more carefull.

> The
> existing proposal is more of a clean break from TIFF

Some people keep saying that, but I totally dissagree. We broke absolutely nothing, except for one single thing (the bitdepth of file offsets), and we broke that one single thing in a totally consistent manner. TIFF minus the particular file offset bitdepth, is still 99.99% of TIFF.

Best regards,

Joris Van Damme
Download your free TIFF tag viewer for windows here: