2004.06.09 20:33 "[Tiff] Re: large TIFF - two alternatives", by Steve Carlsen
At 18:15 -0700 5/26/04, Steve Carlsen wrote:
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 =======================
A. 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.)
B. 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.)'
C. Header bytes 6-7 are reserved and must be zero. (If they're not, a reader should give up.)
D. Header bytes 8-15 contain the 8-byte offset to the 0th IFD.
E. 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.)
F. 8-byte offset to the Next_IFD, at the end of an IFD.
G. to keep IFD entries 8-byte-aligned, we begin with an 8-byte (instead of 2-byte) count of the number of directory entries.
H. add TIFFTypes of LONG8 (= 13), an 8 byte (unsigned) int, and SLONG8 (= 14).
I. StripOffsets and TileOffsets and ByteCounts can be LONG8.
J.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?