LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 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.04.27 06:12 "Re: Large TIFF files", by Rob Tillaart
Gerben Vos wrote: > > Rob wrote: > > > It goes through all tags and replaces all 64 bit tags with 32 > > > bit tags leaving all data on the same position. > > Joris wrote: > > - 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.