2004.04.26 09:58 "Re: [Tiff] Large TIFF files", by Joris Van Damme
It goes through all tags and replaces all 64 bit tags with 32
bit tags leaving all data on the same position.
I think in general, we have a tendency to loose track of some things I think are defenetely a requirement, nonetheless
- as much 'streamabillity' as possible (current library goes back only to write offset to next ifd)
- total relocatability (defenite requirement)
Just my two cents: I don't like the idea of going back and rewriting all IFD.
- Remember that it may be a 3 gig file with thousand IFD's
- it's not at all 'streamable', data isn't 'partly finished' at any stage
- it's not my idea of clean
[fileformat and library are closely related but two different things]
Depends. If there is a complete and independent specification, then, yes, there is a fileformat that is not defined by the library. I vote for feasability instead: changing minor things to LibTiff, so that count/offsets can be 64bit. Adobe may be bothering to write a spec, which is a good thing, but I don't think this list is going to be bothered by that. So it is defenetly possible that the new fileformat is defined by library only.
It is not possible to select allways in advance the right mode, as a user can decide to enlarge a bitmap to > 4GB. When 32 bit mode was chosen and there is a sudden runtime switch to 64bit mode I can imagine quite some difficulties.
=> So the library must work internally in 64 bit mode.
The premis, I agree with, but my conclusion is => so the library user must specify if it wants to write a 32bit or 64bit file in advance, using a flag in the primary TIFFOpen call.
Joris Van Damme
Download your free TIFF tag viewer for windows here: