LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
May 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.05.27 09:25 "Re: large TIFF - two alternatives", by Rob Tillaart
Steve Carlsen wrote: > > Greetings all, > > Alternative 1: Minimal changes for TIFF to support 8-byte addresses > ----------------------------------------------------------------------------------------------------- > a. ID = 43 (or maybe 0x4242?) > b. 8-byte offset to 0th IFD > c. Value/Offset fields are 8 bytes > d. 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 > e. add TIFFType of LONG8, an 8 byte (unsigned) int > f. 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? > Alternative 2: A more modern and general approach > -------------------------------------------------------------------- > (in the following, any power of two can be used instead of 8) > > a. 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. > b. 8-byte pointer to 0th IFD/Dictionary > c. Value/pointer fields are 8 (2**x) bytes > d. 8-byte child pointers > e. add an 8-byte TIFF integer type, but it's rarely used explicitly > f. StripOffsets and TileOffsets and ByteCounts are 8 bytes > > g. 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. But 20 years can pass quickly. > h. use of ASCII tags/keys instead of binary ones > i. most values are ASCII strings, too: integers, floating point > numbers, enums, yielding fewer data types Which not? Why not all? Proprietary tags too? 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. > j. Dictionaries (IFDs) can be really large. > k. Cleaner hierarchical structure, with explicit inheritance from > parents. top-level dictionary contains metadata only; it does not > point to image data. > l. Explicit support for layers > m. All data is planar (though it can be interleaved by row or tile) > n. So there are 4 levels to the hierarchy: Root, Image, Layer, and > Channel. Only Channel dictionaries point to image data. > o. Multi-byte numeric values are always big-endian, not that it > matters very often in this more string-oriented approach. > p. All other rules are normal TIFF rules. Sofar my 2 cents; regards, rob tillaart