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 01:15 "large TIFF - two alternatives", by Steve Carlsen
Greetings all, I haven't been involved in TIFF for a very long time, but I've been talking to Chris Cox about the subject of "Large TIFF", and would like to run a couple of alternatives by this group. The first alternative is, I think, the smallest number of changes possible such that the result cleanly supports 8-byte addresses. The second alternative is the way I would design TIFF if I were doing it over again today, taking advantage of the fact that no old TIFF readers will be able to read "Large TIFF" files anyway, even with the minimal approach. The second alternative is more general, more flexible, easier to debug, supports layers, and simplifies a number of things. I don't _really_ expect to convince everyone that Alternative 2 is worth the new code that it would require (not that any of it is difficult); but I thought I should bring it up because if we're ever going to move to a a more powerful version of the 'old TIFF', there will never be a better opportunity than now. - SteveC 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?) e. add TIFFType of LONG8, an 8 byte (unsigned) int f. StripOffsets and TileOffsets and ByteCounts can be LONG8 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" 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) 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 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.