Thread

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?

Guess so,

Am I missing something?

See above.

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).

Regards,
rob.