2004.04.15 00:26 "[Tiff] Large TIFF files", by Lynn Quam

2004.04.27 06:12 "Re: [Tiff] Large TIFF files", by Rob van den Tillaart

        It goes through all tags and replaces all 64 bit tags with 32
        bit tags leaving all data on the same position.

  • as much 'streamability' as possible (current library goes back only to write offset to next ifd)

Rob's proposal would keep streamability unless you (a) don't know whether you'll be writing 32-bit or 64-bit in advance *and* (b) you want to write 32-bits downward compatible TIFF as long as that's possible. I think that's reasonable. You can have two, but not all three. He's just extending the possibilities. We don't have to implement it yet (see my later comments on the specification vs. the library).

That's what was meant, if you know the format in advance (64 or 32) you just write and do not need to fix. But if the lib don't know in advance (also not forced to 32) the lib should write 64. When in retrospective it sees the file is under 4 GB it may rewrite all offsets to keep 32 bit compatibility.

This step is optional and only needed if one wants to enforce 32 bit compatibility as much as possible. This rewriting of offsets prevents streaming (or you must have at least a 4GB buffer :).


How much effort would it be to implement a basic 64bit version of the library? focus only on the offsets of IFD, tiles and strips and???

Such prototyping action could reveal much insight in the additional problems. These additions could be made conditional with a #define flag, so there still is one code base.