|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
2004.04.26 11:38 "Re: Large TIFF files", by Gerben Vos
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). > - total relocatability (definite requirement) Not sure what you mean here. Do you mean that it should be possible for everything to appear anywhere in the file? I.e., everything should be addressed by 64-bit offsets? Although it may be the best thing to do, I'm not so sure if it's a definite requirement. > Just my two cents: I don't like the idea of going back and > rewriting all IFD. Only in a particular case. I suppose a libtiff user would have to turn on this behaviour. Streamability is important for some people, but it isn't necessary for everyone. I think it could be a reasonable way to have some extra backwards compatibility. > > [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 think it is an absolute must that there is a complete specification (whoever makes it). Having the format defined by the library would make updating existing non-libtiff implementations to 64 bits almost unfeasible. > I vote for feasability > instead: changing minor things to LibTiff, so that > count/offsets can be 64bit. Yes, that would be my idea too, but then change the spec as well as libtiff. Note that this is largely independent of your previous sentence! > 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. We have let that bother us for many years, why stop now? :-) I'm not so sure libtiff or this mailing list has enough leverage to establish a de-facto standard. Better to have Adobe and some other major players (Kofax or other scanner manufacturers?) on board. > So it is definitely possible that the > new fileformat is defined by library only. No, even if we would go solo, we should produce a comprehensive specification. See how long PNG needed to take off even *with* a good spec. With only a reference implementation, our attempt is doomed. > > 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. Yes, the library should always internally work with 64 bit pointers, also to prevent doubling the code size, but it should be possible for a user to specify in advance which of the two is going to be written. Or maybe even leave it open. Gerben.