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.04 20:52 "Re: BigTIFF extension", by Joris Van Damme
Folks, 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. 2) LibTiff, as well as AsTiff and probably any TIFF library in the future, is completely transparent as to reading ClassicTIFF and BigTIFF. It automatically gets the necessary version information from the header, and acts accordingly, without needing the caller's awareness. That is, first time awareness of particular TIFF version comes about, is long after filename decision, at a level much deeper, and the version issue ought to not get to the caller level nor user level. Hence, it stands to reason both ClassicTIFF and BigTIFF would have the same extension. 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. 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. I've chosen against supporting and promoting this, because it leads to major space waste inside the file as many structures need to be rewritten and reappended as part of the transition to BigTIFF (and I have some additional reasons too). However, it may turn out some people need this and if so we'll implement it anyway. We need to keep the option open, even if we decided against it for now. Now think of the consequences as to file extension: will we automatically change 'something.tif' to 'something.btf' while writing the file, depending on the accumulating size? That would be unprecedented and would cause major headaches. 5) The majority of important software that is well maintained and uses LibTiff, will automatically have BigTIFF reading support as they upgrade to LibTiff 4.0. However, if we also change the extension, that has consequences that are not automatic in many Windows software, we will need maintainers to remember going in and changing file extension filters for file open dialogs. Many will fail to do this, and BigTIFF reading support will de facto not penetrate the market nearly as thoroughly and rapidly. 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 realize I host BigTIFF example files since the beginning of times that have extension '*.btf', since that was the consensus at the time I brew these. However, I'll try and get around to changing them to read '*.tif' instead, some time today. 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