2004.04.26 11:28 "Re: [Tiff] Large TIFF files", by Joris Van Damme
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.
Your earlier question is also valid for the library user (programmer): It does not always know in advance if it needs 32/64 bit.
Yes, that is true. Thus, my reasoning:
- Such tricky descisions should be left to the higher level, not the lower, as at least on that level there *may* be more information available, and at least that way it's the library user's responsability to select. (Remember the library user (code) selects tiles or strips. So why shouldn't he be the one to select 32 or 64bit flavor?)
- The added benefit over 'late auto-selection' is cleanness, comprehensability, added streamability, less hassle to implement and thus less error-prone, more likely to get implemented in other tiff libraries, etc.
Don't get me wrong, I'm not contradicting your assessment that it is a major problem, nor am I contradiction that the way I propose things doesn't quite solve the tricky descision to make. I am concerned however with cleanness, user control, and just being plain logical. Consider what happens in your scheme if a file is first written as 64bit, then corrected to be 32bit because it is 'only' 3.8 gig, and next it is reopenned and pages are appended causing a need to grow beyond 4gig... It is these considerations that lead me to believe application should decide in early stage, not library in late stage.
I expect that after such experience most programmers will select 64 bit, or there must be a hard requirement for 32 bit only.
In time, like couple of years or so, that is bound to happen either way (if ever we stop rambling and do some actual work, that is). It is not a bad thing.
Joris Van Damme
Download your free TIFF tag viewer for windows here: