1<html> 2<head> 3<title>BigTIFF Design</title> 4</head> 5<body> 6 7<h1>BigTIFF Design</h1> 8 9<p>This is the HTML equivalent of a former Wiki working place for preparing a 64-bit (larger than 4GB) TIFF 10format specification. The design is based on a proposal by Steve Carlsen of Adobe, with input from various 11other parties.</p> 12 13<h2>Briefly</h2> 14<ul> 15<li>Version = 43</li> 16 17<li>8-byte offset to first IFD</li> 18<li>Value/Offset fields are 8 bytes</li> 19<li>8-byte offset to the next IFD</li> 20<li>add TIFFType of LONG8, an 8 byte (unsigned) int</li> 21<li>StripOffsets and TileOffsets and ByteCounts can be LONG8</li> 22</ul> 23 24<h2>More Detail</h2> 25<ul> 26<li>The Version ID, in header bytes 2-3, formerly decimal 42, now changes to 43</li> 27 28<li>Header bytes 4-5 contain the decimal number 8.<ul> 29 <li>If there is some other number here, a reader should give up.</li> 30 <li>This is to provide a nice way to move to 16-byte pointers some day.</li></ul></li> 31<li>Header bytes 6-7 are reserved and must be zero.<ul> 32 <li>If they're not, a reader should give up.</li></ul></li> 33<li>Header bytes 8-15 contain the 8-byte offset to the first IFD.</li> 34<li>Value/Offset fields are 8 bytes long, and take up bytes 8-15 in an IFD entry.<ul> 35 36 <li>If the value is <= 8 bytes, it must be stored in the field.</li> 37 <li>All values must begin at an 8-byte-aligned address.</li></ul></li> 38<li>8-byte offset to the Next_IFD, at the end of an IFD.</li> 39<li>To keep IFD entries 8-byte-aligned, we begin with an 8-byte (instead of 2-byte) count of the number of directory entries.</li> 40<li>Add TIFFTypes of LONG8 (= 16), an 8 byte (unsigned) int, and SLONG8 (= 17).</li> 41<li>Add TIFFType IFD8 (=18) an 8byte IFD offset.</li> 42<li>StripOffsets and TileOffsets and ByteCounts may be LONG8 or the traditionally allowed LONG or SHORT.</li> 43 44<li>The proposed extension is ".tf8", and call it "8-Byte TIFF".</li> 45</ul> 46<p>Otherwise, it's just like "original TIFF." ("TIFF Classic?")</p> 47 48<h2>Open Issues</h2> 49<ul> 50<li>What to call the new format<ul> 51 <li>ChrisCox -- I don't think end users will understand what "8-byte TIFF" means</li> 52 <li>AndreyKiselev - 23 Sep 2004 -- What about TIFF64? "64" is a widely used buzzword and should be directly associated with the 64-bit offsets and 64-bit architectures.</li></ul></li> 53 54<li>What 3 character file extension to use (gotta be DOS compatible)</li> 55<li>What 4 character file type to use (for Macintosh)</li> 56<li>What MIME type to use</li> 57</ul> 58 59<h2>Samples</h2> 60<p><a href="http://www.awaresystems.be/imaging/tiff/bigtiff/BigTIFFSamples.zip">Example files</a> from Joris Van Damme</p> 61 62<h2>Changes</h2> 63 64<ul> 65<li>TIFFType 13 is ttIFD, 14 is assigned to ttUnicode, and 15 is assigned to ttComplex. So, I changed the types for ttLong8 and ttSLong8 to 16 and 17, respectively.<ul> 66 <li>AndreyKiselev - 23 Sep 2004 -- Where are these fields defined? Is there any new Technical Note or something? And what is encoding behind the word "Unicode"?</li> 67 <li>ChrisCox - 27 Sep 2004 -- They are in the Adobe TIFF definitions. I am still working on releasing updated TIFF documentation.</li></ul></li> 68<li>Added list of open issues.</li> 69<li>settle on version 43</li> 70<li>cleanup</li> 71<li>TIFFType 18 (8 byte IFD) added.</li> 72 73<li>Clarified that fields which may be LONG8 can also be one of the old supported types.</li> 74</ul> 75 76<h2>See also</h2> 77<p><a href="http://www.awaresystems.be/imaging/tiff/bigtiff.html">AWare Systems' informal overview of the BigTIFF proposal</a></p> 78 79</body> 80</html> 81