2004.04.26 12:50 "Re: [Tiff] Large TIFF files", by Joris Van Damme
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).
Either you didn't understand Rob, or I didn't, or you didn't understand me, or I'm not understanding you. Or something. Not quite sure.
Further down you write:
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.
Rob said: internally start working with 64bit pointers, correct to 32bit if upon closing filesize <4gig
I said: better let user specify in advance.
Or at least, I think we said that, but you're confusing the hell out of me. ;-)
- - 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.
Yes, that is what I mean. In my humble opinion, that is like *the major* corner stone of the format.
Just my two cents: I don't like the idea of going back and rewriting all IFD.
Only in a particular case.
Particular case being: all 32bit tiffs, all tiff <=4gig. If I understood Rob correctly. That's about 99% of the files we expect the library to write first year or so, I guess, so it may not be that particular a case at all.
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.
Again, you're really confusing the hell out of me. I'm not sure what exactly 'some extra backwards compatibility' referers to.
[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.
OK, I'm not going to argue about that, you may be very right in stressing the importance of good spec. But I still also stress that I'd like to see *something* happening, besides this discussion, either way.
Note that my proposal (logically forking all reference to 32bit count/offsets in libtiff to either 32bit or 64 bit depending on a single flag in the TIFF structure that gets set with a parameter of new TIFFOpen call, and adding a single datatype, *not* changing anything else, *not* changing tag codes, meanings, or anything, plus keeping single tiles/strips restricted to <4gig) probably takes less effort then the combined effort of this discussion already, and is clean and easilly communicated, this is likely to be equally easilly adopted by non-libtiff implementations.
Note that this is largely independent of your previous sentence!
My subtle attempt was to link both seemingly unrelated things with the word 'feasability', implying that whether things do or do not start moving may depend upon whether we choose to discuss seemingly grand things like re-inventing some wheels or to simply do the job that needs to be done.
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 can see I expressed myself badly. I meant to say the list is most probably not going to bother with writing a spec. But of course we do like Adobe to take care of that, of course I'm awaiting TIFF 7.0 spec, as we all have been for what seems like decades. Of course I care!
Note that Chris seemed to have implied that a TIFF 7.0 spec may actually be in the pipeline. I think we ought to consider hiring a group of chearleaders or something for moral support.
Joris Van Damme
Download your free TIFF tag viewer for windows here: