2006.07.24 01:46 "Re: [Tiff] BigTIFF Implementations", by Joris Van Damme
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.
> Head Software Engineer
> Diagnostic Instruments, Inc.
> lmichaels@diaginc.com