2004.10.01 07:22 "[Tiff] BigTIFF extension issue", by Joris Van Damme

2004.10.01 17:48 "Re: [Tiff] Re: BigTIFF extension issue", by Joris Van Damme

Nevertheless, I don't really mind using ".tif", especially if developers on this list and any other developers we can influence would attempt to use guidelines for new releases such as:

When writing a BigTIFF file, we let the user know, with a warning something like:

"Given the file size, note that you are creating a special "Big" TIFF file, which may be incompatible with some applications."

I can agree with that. In fact, I think speaking Photoshopish now because it really depends on the app, that writing Classic or Big TIFF should be a consious user decision, just like today the byte order and compression scheme is. I think this has been discussed before: due to the nature of TIFF, the LibTiff layer cannot decide what flavor to write. When starting the writing, it cannot know what is going to follow, nor with what ratio it is going to be able to compress. Plus, any number of things may next happen on the written TIFF file, including appending a huge number of huge pages. In many cases, the app has the same problem. So, in many cases, including the Photoshopish class of apps, the user should be able to make the final descision.

When readers encounter such a file, if we can't deal with it yet, we let the user know in some helpful way such as "This type of TIFF file is not yet supported." rather than just reporting "Unknown Format" or some such thing.

While LibTiff does not yet support BigTIFF, it could be very easy to nevertheless update it to already recognize at least the BigTIFF header already, and return the appropriate error message you mention here, instead of a generic 'not a tiff file' - ish error. Since many apps stay reasonably up to LibTiff date, that should already come a long way towards meeting your wish.

Joris Van Damme
Download your free TIFF tag viewer for windows here: