2004.10.02 03:43 "Re: [Tiff] Re: BigTIFF extension issue", by Chris Cox

And we can't go back and update Photoshop 4.0 (still in use!) to support BigTIFF, or to make it give a reasonable error message -- it's just going to say "this isn't a valid TIFF file".

I assume that Photoshop 1.0 is saying the same about a tiled TIFF. (I may of course have version numbers and dates incorrect, but I mean to address the general issue, of course.) Why was this not a problem back then?

It has always been a problem with newer versions of some file formats.

As far as Photoshop 4.0 is concerned, BigTIFF is indeed not a valid TIFF file. It is not uncommon for applications to not be able to foresee future incompatible versions of file formats, users do know that, and expect Photoshop 4.0 to eg not know what a DNG file extension means. That is merely logical, no user expect up to date behaviour from an outdated version.

No, users DO expect that TIFF will be compatible across versions. They raised quite a stink (threatening boycotts) when Photoshop added FLATE compression and transparency support to TIFF because their older applications couldn't deal with it.

Incidently, Photoshop 7.0 is unable to read my YCbCr subsampled images. There's plenty of other TIFFs it can't read. And that's pretty normal, anyone used to TIFF knows that even the best of apps usually supports the reading of a limited subset of TIFF.

No, Engineers know that - customers don't.

I'd like to bring some focus to the most general question: is this a new file format, or a new version of an existing format? It wouldn't hurt to draw the logical conclusion about the file extension and such, after answering that question - that is, I think, the way it's always been done before. Right? Nobody even suggested changing name to 'Tiled TIFF' and extension to '.ttf', I'm reasonably sure.

It is a new version of a file format.

But that doesn't mean that customers will understand that distinction. (they didn't understand PSD 2.0, so we had to give it a new name and extension: PSB).

From this point of view, current applications refusing the new BigTIFF, has nothing to do with the current applications, but everything with the fact that we chose to not design BigTIFF to be backwards compatible with classic TIFF readers, for which we had very good reasons. One backwards compatible option was explored (http://www.asmail.be/msg0055356585.html), but it was quite rightly quickly judged to be way too much hassle and way to ugly.

I feel the primary issue is: Is BigTIFF a new version? Or is it a new file format? Let's decide, and be consistent, is what I propose. Do you plan to write a new spec, or write a new version of the spec, that should give some indication as to this question, and do we plan to design new codecs, or write new versions of the existing ones? Seems that's all very related. If this is merely a new version of an existing file format... It is extremely uncommon at the very least to have version dependent file extensions, is it not?

Engineering concerns can be consistent.

But end users are only consistent in one way: they just want it to work.

Chris