2004.04.26 07:30 "Re: [Tiff] Large TIFF files", by Rob van den Tillaart

Most important is that any file which does not in fact exceed 2GB must be readable by old code.

I think there may be consensus about that, the point has been raised before, but little has been said about how exactly to achieve this.

The library cannot know in advance how large the TIFF to write is going to be, right? In fact, it's quite possible that the library user / application code does not know in advance, even disregarding unpredictable compression factors.

Can the library know in advance? If it does it can make an optimal choice (32 or 64 bit);

I assume this choice can be made per image (in case of an multipage) which leads to the question:

With a 64bit extention to the current format is it acceptible to have both 32 bit offsets and 64 bit offsets used together?

if the library does not know the size in advance it must use 64 bit.

Q: Can the library know the filesize afterwards?

Yes it can most of the times.

<scenario>
        A tiffwriter has written 64bit tiff file.
        When ready it detects filesize < 4GB so 64 bit was not needed.
        It goes through all tags and replaces all 64 bit tags with 32
        bit tags leaving all data on the same position.
        This tag postprocesing can be fast.
        Drawback is quite some 32 bit holes in the data
        but very backwards compatible!
</scenario>

When postprocessing is not an option, e.g. the data is written to a stream and the writer does not know the final size it should use 64 bit.

Note: This scenario implies that the library internally works in 64 bit mode.

[fileformat and library are closely related but two different things]

Bob raised the hope that a simple redefinition of some types may allready do the job. I'm not a C man myself, wouldn't know for sure, but does this not exclude 32bit and 64bit TIFF living in the same library? If I'm not mistaking, this is the way LibJpeg supports both 8 and 12 bit jpeg, but one needs two seperate compiled LibJpeg libraries to support 'em both in the same app as a consequence. But I'm not a C man, please point out the errors in my thinking.

Is it then an option to include a boolean 32bit/64bit selector in the main LibTiff TIFF structure instead? Thus allowing applications to select either bitdepth *in advance*, for example by means of a flag of some sorts in the TIFFOpen/TIFFClientOpen call? And rewriting some of the IFD handling code to deal with either case?

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.

regards,
rob