2004.05.27 01:15 "[Tiff] large TIFF - two alternatives", by Steve Carlsen

2004.05.27 14:00 "Re: [Tiff] large TIFF - two alternatives", by Steve Carlsen

  1. 8-byte offset to the next IFD (does anyone use this?)

Is needed if one wants to add an IFD after the 2G/4G barrier

I meant 'does anyone use offset-to-next-IFD instead of child pointers?' Clearly, if offset-to-next-IFD is used, it must be 8 bytes like the rest of the pointers.

  1. add TIFFType of LONG8, an 8 byte (unsigned) int
  2. StripOffsets and TileOffsets and ByteCounts can be LONG8

You allow the mix of 4byte and 8byte offsets in one file? OK.

Should the file extention still be .TIF(F)? or one of the others proposed earlier?

I think it should be different, to avoid confusion for both software and end users.

  1. ID = the string "TIFF2"

Why not making the string 8 bytes (e.g. TIFF2004) so all fields are 8bytes aligned.

=> easier for 64 bit architectures.

Whatever the string, I'm assuming that the string would be padded with nulls on the right (if necessary) to make it 8 bytes, and that, in general, values should begin on at least 4-byte boundaries, if not 8-byte.

  1. support for 4 or 8 or 16 or ... 2**X byte addresses (header tells which one you're using)

This will complicate things and I expect that we do not need an 16 Byte or larger adressspace soon. 8 bytes will give an address space of 18.446.744.073.709.551.616 roughly a million times the largest harddisks today. As disks double in capacity every year it will take approx. 20 years before 8 bytes is not enough.

Yes, yes, all true. I'm actually more interested in the small side -- having a single format that supports both 'old tiff' 4-byte offsets as well as the newer 8-byte offsets, probably _not_ mixed within the same file. But it's nice to be thinking ahead, too. Just because 16-byte offsets are defined does not mean that everyone will write software that is general enough to use them. Just fail gracefully, with a nice note to the user.

That said, using something like C++ templates for implementation of certain parts of the code could make support for 16-byte (and 4-byte) offsets come 'for free.'

But 20 years can pass quickly.

Yes; TIFF is indeed almost 20 years old.

  1. use of ASCII tags/keys instead of binary ones
  2. most values are ASCII strings, too: integers, floating point numbers, enums, yielding fewer data types

Which not? Why not all? Proprietary tags too?

I'm assuming _all_ tags (keys) are ASCII, and fit within a certain space within an IFD (Dictionary) record -- probably 8 bytes.

In the big tiff discussion there was also someone who stated that string key/val would ease the recovery of corrupted TIFFfiles. This could be done automatically if every IFD gets an IFD signature e.g. a string "TIFF_IFD" as first field.

Yes, this could be valuable.