LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2007
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2007.07.09 14:10 "Re: BigTIFF extension", by Joris Van Damme
Gary, Gary McGath wrote: > 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 info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html