LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 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.04.20 08:29 "Re: Large TIFF files", by Rob Tillaart
[the discussion continues] Hi, The discussions of the 64 bit TIFF bring up some good insights (requirements?) There are in essence only 2 routes for 64 bit tiff - compatibility with existing - breaking with existing (but keeping as many good things as possible) The first leads to all kinds of trouble as mentioned in earlier mails. Frank proposed a new 64 bit format BTIFF (or BIF: Big Image File or BIg File) and for now this seems to me the most promissing way. BIF could inherit the tag structure of TIFF with some 'minor' changes. Who are the stakeholders for 64 bit. 1) applications that make huge images or (eg www.jumboscan.com) 2) applications that make huge multipage images (eg highres video camera) 3) applications that do both. It seems to me that many applications will not need 64 bit. PRELIM. PROPOSAL BIF ----------------------- All types will be mapped upon signed 64 bit, alignment to 64 bit or 8 bytes TYPES ----- 1 = ASCII string 0 terminated 2 = BLOB bytearray 3 = DOUBLE 4 = LONG64 5 = RATIONAL64 LONG64/LONG64 (16 bytes) 6 = COMPLEX LONG64-LONG64 (16 bytes) All nummeric types are signed, this would make files max. 2^63 bytes in stead of 2^64 seems large enough for now. 2^63 = 9.223.372.036.854.775.808 All (tiff32) types are mapped upon long64 (even boolean) This seems a waste of bytes but if we talk about files >> 4GB these few bytes won't matter too much I assume. HEADER --------- Bytes 0-1: endianess // must we keep this ? Bytes 2-7: SAM 64 // in ASCII Bytes 8-15: 64 bit IFD offset // 0000000 for last IFD The number of directory entries is also a LONG64; TAGS ----- Byte 0-7: tag Byte 8-15: type Byte 16-23: value (type=3-6) length (type=1,2) Byte 24-31: opt. value (type=5,6) 64bit offset (type=1,2) Tag's are the same as in the TIFF 6.0 spec. preceded with 0's. The range with the first 32 bit a 0 are reserved for this 'compatibility' The range with the first 32 bit a 1 are reserved for 'the commitee' (whoever ...) METATAG ---------- There is one new TAG the metaTAG FFFFFFFF-00000001 // Metatag 00000000-00000001 // ASCII some length offset --> data data = "XXXXXXXX-XXXXXXXX:description" X = value of a new tag used in this file example data: "11111111-00000001: A tag for internal use of application X only." this way applications can extend the metadata in a documented way. Note that the tag is not registered in any way and only valid for this file. END PRELIM PROPOSAL I didn't think about the image data yet but for now compressions are just same, tiles and stripes are just as usual only they have a 64 bit offset/count. I think it is good practice to keep tiles small. So far my thinking about the large tiff files for now, Please shoot: comments, remarks, questions, ideas, improvements, alternatives, ... best regards, rob tillaart [and the discussion continues ...]