LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
October 2004
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
2004.10.02 03:43 "Re: BigTIFF extension issue", by Chris Cox
At 3:21 AM +0200 10/2/04, Joris wrote: > > 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