1997.05.02 07:04 "BIG TIFF file problems", by Hans Christiansen

1997.05.02 12:45 "RE: BIG TIFF file problems", by Niles Ritter

Even though this is more of a TIFF problem than a libtiff problem, I would like to make others aware of the limitations of TIFF - and stdio - that we are running into.

Yes, this is an intrinsic problem of all 32-bit architectures. You can have HUGE disks, and you can stream through huge files, but you can't easily have random-access seek's to huge files with just 32 bit offsets.

If anyone knows about plans for getting around either of these problems in TIFF 7.0, I'd sure like to hear about them.

I doubt it will make the TIFF 7.0 spec, which is under review somewhere (are you still out there, Brian?). TIFF 8.0 maybe.

This would a fundamental change in the structure of TIFF, as such, which has 32-bit offsets everwhere. I would venture to say that to change this part of TIFF would require changing the version number from 42 to 56. (a gin-and-tonic to the first person to get this obscure half-joke).

IMHO, 64-bit TIFF could be done in a way that at least gives some hope of backward compatibility. The very first thing that needs to be defined is a "LONG64" field type, which is an unsigned 64-bit integer value.

The file could start with a valid first TIFF IFD, which is, say, a 32-bit "thumbnail" of the BIG image. Needless to say, this entire thumbnail must reside in the first 2GB of the image. The thumbnail image directory contains a tag of type LONG64, which is the 64-bit offset to the start of the first 64-bit TIFF image directory. It's structure would probably be some 64-bit flavored version of the 32-bit one, which is TBD.

TIFF 6.0 compliant readers will just issure a warning about the strange field-type and tag, and go on its merry way with the thumbnail.

Incidentally, I think you can just about address every atom on the planet earth with 128 bits, so we don't have too much further to go with this stuff. Let's see, Avogadro's number is 6.02 x 10**23 (p/mol)...

--Niles.