2004.10.02 10:20 "Re: [Tiff] Re: BigTIFF extension issue", by Andy Cave

Hi All.

Lots of mails on this subject, so I'll add my £/p worth.

I don't think you can use the argument that no existing standard TIFF reader can read BigTIFF. The case of tiled tiff vs previous tiff is one example, but perhaps not a good one. So, take PostScript or PDF as perhaps a better example. We had PS Level 1, then Level 2 then Level 3. We had PDF 1.0, then 1.2, then 1.3, then 1.4. I think everyone would agree that there was no new file format. But no laserprinter that was Level 1 could print a Level 2 file. In this case one would argue that the file format was the same, but the commands/operators were different.

Re BigTIF, I think the file format is the same, but the data types are different (an 8 byte offset data type instead of a 4 byte). In fact I think one could argue that TIFF already supports varying data types of different byte lengths, albeit for tags, as values can often be SHORT or LONG etc... I think a 64bit offset type vs a 32bit offset type is exactly the same thing, but just applied in a different place (for offsets & sizes et al).

The actual format of the file is the same (header, offset tables, etc... compressed bands, tiles,...).

Re JPEG vs JPEG2000, the file format is not the same, as the file is only the compressed data stream, which is different. So, here I can see why a new extension was required.

If there is a tag in there indicating it's big tiff, apps can very soon rev to support this and give a warning. People have to upgrade their apps periodically, as older apps don't even run on later OSs. So within a few years all (most) the apps people use will deal with big tiff .tif[i] file correctly. And big tiff files will only be common in general open use (as opposed to closed loop systems) in a while anyway.

Yes sticking with .tif[f] does put pressure on us as a company to support it, as otherwise we get lots of support headaches. But then to stay competitive, we'd need to do this anyway. So it's a meaningless argument.

I think we should stick with .tif[f].

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.hamillroad.com