LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2006
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
2006.07.24 02:28 "Re: BigTIFF Implementations", by Larry Michaels
Joris, I regret that I was not involved in the discussion about the BigTIFF file extension in 2004, but BigTIFF support was not on our agenda at the time. I fully appreciate the arguments for preserving the "tif" file extension, but for our purposes and market, I am afraid that it will cause us more problems than it would help. Our customers and dealers often expect to open the files which we create in various other applications and complain to our support people when those other applications display illogical error messages and/or crash (which some do). The software vendors, some with business-political agendas, will often tell the customer when they call for support that the problem is our fault. As far as I am aware, none of the other applications which our customers commonly use currently support BigTIFF, and so our using "tif" as the BigTIFF file extension would be like begging for support calls. The customers will not understand the difference between the different varieties of ".tif" files. I realize that the same arguments can be made for tiled TIFFs and various types of compression which may not be supported by all applications, but since there is currently about a 0% chance of success for one of our customers opening a BigTIFF in another application, I would prefer to avoid problems by using an extension other than "tif". Our application will read BigTIFF files with the "tif" extension though. I suppose that the real question is not what the official BigTIFF file extension should be, but rather what will considered as a reasonable alternative extension. Larry Michaels Joris wrote: > Larry, > > Please include the mailing list in your mail recipients. Any BigTIFF > discussion certainly is valuable for subscribers and archive users. I've > included a bad-style complete quote at the bottom of this mail to > compensate. > > Larry Michaels wrote: >> I appreciate your very quick reply. You're interpretation of the >> images is mostly correct, except that the files with "2Images" in >> their names each contain two IFDs. Each image also includes a few >> tags such as Software and ImageDescription. If you do eventually >> discover any warnings, I would appreciate your passing them along to >> me. > > I'm in the midst of rewriting the old codec from Delphi to C++. Thus, > currently, all is a bit of mess. I can't even easilly examine the second > IFD. > > I'll try and examine your files more thoroughly with previous Delphi > version of the codec, when I have a little more time. If you don't hear > back from me within a week, please feel free to remind me. > >> I don't really care what extension is used, but I >> would definitely prefer to distinguish the file extension from >> traditional TIFFs because if we use the same extension, our users >> will be more likely to save their images in BigTIFF format, try to >> open them in another application which does not support the format, >> and then complain to us that our files are bad (everything is always >> "our fault"). Using a unique file extension will prevent or at least >> discourage users from trying to open the files in apps which cannot >> read them. Some of the high-end imaging applications which our >> customers use like to crash when trying to read files that they don't >> like, so it benefits us to prevent these situations. > > One of the entertaining aspects of the mailing list discussion on the > extension, was that both parties used pretty much the same arguments. > For example, the argument was given that users nagging vendors is > actually a good thing as it will speed up the growing of support for > BigTIFF. Another argument that was offered in response to arguments much > like yours, is that pretty much the same thing happened when TIFF > started including the tiling scheme. Yet, extension remained unchanged. > So there is a precedent for this situation. > > Anyway, I see little use in having that discussion all over again, > unless there are new arguments, and/or someone with some authority like > Frank or Chris is willing to draw a final decision on the topic this > time. Until that happens, after weighing all arguments offered in that > discussion, I'm inclined to prefer .tif. Apart from many other secondary > reasons, this is mainly because, at the end of the day, I don't think > BigTIFF can be considered another file format. It is, instead, a new > flavour of the old format, in my personal opinion. > > Like I said back then, when I go and have a haircut, I don't logically > need to change my car's licence plate as a consequence of that action. > > > 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 > > > Larry Michaels wrote: >> Joris, >> >> I appreciate your very quick reply. You're interpretation of the >> images is mostly correct, except that the files with "2Images" in >> their names each contain two IFDs. Each image also includes a few >> tags such as Software and ImageDescription. If you do eventually >> discover any warnings, I would appreciate your passing them along to >> me. >> >> I haven't closely followed the various discussions, so I was under >> the impressions the "tf8" was the de-facto file extension. I noticed >> that a utility called Imageconverter Plus >> (www.imageconverterplus.com) refers to "tf8" as one of their >> supported formats. I don't really care what extension is used, but I >> would definitely prefer to distinguish the file extension from >> traditional TIFFs because if we use the same extension, our users >> will be more likely to save their images in BigTIFF format, try to >> open them in another application which does not support the format, >> and then complain to us that our files are bad (everything is always >> "our fault"). Using a unique file extension will prevent or at least >> discourage users from trying to open the files in apps which cannot >> read them. Some of the high-end imaging applications which our >> customers use like to crash when trying to read files that they don't >> like, so it benefits us to prevent these situations. >> >> Thank You >> >> >> Larry Michaels