2004.06.09 20:33 "[Tiff] Re: large TIFF - two alternatives", by Steve Carlsen

It seems like the prevailing opinion is for making "Large TIFF" be mostly just like existing TIFF except for supporting 8-byte addresses.

Making the "Alternative 1" proposal a bit more concrete, then, and adding some 8-byte alignment language and a hook for future expansion:

============================= 8-Byte TIFF =======================

1. The ID, in header bytes 2-3, formerly decimal 42, now changes to 0x4242. ( I really like the '42', and this seems like a nice way to have my cake and eat it, too.)
2. Header bytes 4-5 contain the decimal number 8. (If there is some other number here, a reader should give up.) (to provide a nice way to move to 16-byte pointers some day.)'
3. Header bytes 6-7 are reserved and must be zero. (If they're not, a reader should give up.)
4. Header bytes 8-15 contain the 8-byte offset to the 0th IFD.
5. Value/Offset fields are 8 bytes long, and take up bytes 8-15 in an IFD entry. (If the value is <= 8 bytes, it must be stored in the field.) (All values must begin at an 8-byte-aligned address.)
6. 8-byte offset to the Next_IFD, at the end of an IFD.
7. to keep IFD entries 8-byte-aligned, we begin with an 8-byte (instead of 2-byte) count of the number of directory entries.
8. add TIFFTypes of LONG8 (= 13), an 8 byte (unsigned) int, and SLONG8 (= 14).
9. StripOffsets and TileOffsets and ByteCounts can be LONG8.
10. The extension is ".tf8", and the format is called "8-Byte TIFF".

Otherwise, it's just like "original TIFF." ("TIFF Classic?")

===================================================================

Are we close to general agreement? Am I missing something?

Regards,

Steve Carlsen