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.05 05:07 "Re: BigTIFF extension", by Joris Van Damme
Toby, Toby Thain wrote: > > I feel the whole discussion on the extension missed several > > important points. > > > > 1) BigTIFF is TIFF. If I get a haircut, that is not logically > > sufficient reason to also change my car's licence plate. You forgot to answer 1). > > 2) LibTiff, as well as AsTiff and probably any TIFF library in the > > future, is completely transparent as to reading ClassicTIFF and > > BigTIFF. > > This is great, but as we know, the real world mostly uses far > crappier code. The real world mostly uses LibTiff, and it's LibTiff we're talking about. > > 3) When it comes to writing, LibTiff as well as AsTiff and probably > > any TIFF library in the future, takes the desired version as an > > option, just like it lets you choose byte order as an option. If > > this option is propagated to the user, it would stand to reason > > that this option is presented in the normal flow of a GUI long > > after file format (and hence file extension) decision has been made. > > "One day..." What, one day? 95% of the world and software presents the same single GUI workflow for saving files: a) let the user decide on the file name and format (and thus extension) in a first dialog b) let the user decide on the options that come with the chosen file format in a second dialog If ClassicTIFF and BigTIFF get another extension, the choice for either needs to be made in step a). That means that you have to be counter-intuitive in step b), and present two same dialogs for the options of two supposedly different file formats. It may even mean you have to size-estimate the TIFF file before step a), if you want to exclude ClassicTIFF for TIFFs smaller then 4 gig, and such nonsence. If ClassicTIFF and BigTIFF get the same extension, the choice for either needs to be made in step b), meaning that programmers have to merely add another option to an existing dialog where there are already options for byte order and the like. The application layer reflects the choice in a TIFFOpen call option character, just like it does for byte order. This is intuitive, logical, and easy, as are the usual consequences of sticking with choices that reflect actual reality. This is not a 'one day' issue, this is BigTIFF as is in LibTiff 4.0, this is how what we're discussing right now will apply to 95% of the application users, though it may seem like science fiction if you're living a command-line legacy. > > 4) Currently, LibTiff 4.0 does not allow you to start writing > > ClassicTIFF and automatically revert to BigTIFF if the file starts > > exceeding size limits. ... You forgot to answer 4). > > 5) The majority of important software that is well maintained and > > uses LibTiff,... > > Which is the minority of "software people actually use". Got numbers? Some parts of the world are build from 90% abandonware. If you're living in that corner, I figure you might think most software doesn't ever upgrade. But it seems an obscure little corner from where I'm standing. It doesn't seem like the abandonware corner will have much use for BigTIFF, either, anyway. > > In my mind, the whole discussion is moat, though. Let's just stick > > with the actual truth: BigTIFF is a cosmetic operation, BigTIFF is > > TIFF, so the extension '.tif' stands. > > I hate to see this discussion prolonged as much as anyone, but it > would be nice to see the *disadvantages* of this policy somehow > acknowledged. Discussions where everyone just sheds light on his own point of view are mostly useless. Things become more useful if you try and disprove the other party's arguments. But even then, things remain useless if there's no clear authority that derives conclusions (unless the unlikely happens and one party is actually persuaded by the other party's argument). That's how the previous round of extension discussion was rendered a waste of energy: there was no conclusion. It's likely this round will end in the same void. So in the end, the majority of application programmers will decide what is most convinient and intuitive for them. It'll be '.tif'. 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