2004.06.10 07:37 "Re: [Tiff] Re: large TIFF - two alternatives", by Rob van den Tillaart
- 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.)
0x42 is a 'B' so 0x4242 = "BB" (BIG BLOB? :)
- 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.)'
You mean 0x0008; leaves room to grow to 0x1000 (4096) byte pointers giving an address space of 2**32768 ~ 10**9864 bytes. You're thinking really big.
- Header bytes 6-7 are reserved and must be zero. (If they're not, a reader should give up.)
I think the reader should notice but can proceed at own risk.
- add TIFFTypes of LONG8 (= 13), an 8 byte (unsigned) int, and SLONG8 (= 14).
please also add:
- RATIONAL8 LONG8/ LONG8 (16 bytes)
- COMPLEX LONG8, LONG8 (16 bytes)
- StripOffsets and TileOffsets and ByteCounts can be LONG8.
I would like to make a must of that. keep things 8 bytes aligned.
- The extension is ".tf8", and the format is called "8-Byte TIFF".
Breaking the file-extention is imho not alternative 1. The file extention should still be .tif or .tiff
Are we close to general agreement?
Am I missing something?
I know that there does not exist an average TIFF file but a tickling question is how much an average (<2GB) tiff file would increase by using this scheme.
IFD entry is now new
tag 2 8
type 2 8
count n 4 8
value/offset 4 8
total 8 + n x 4 24 + n x 8
The size of an IFD will grow by a factor 32/12 < 3. (when no tiles are used) but when tiles are used the growth factor will be closer to 2. (due to 8 byte alignment).