|AWARE [SYSTEMS]||Imaging expertise for the Delphi developer|
|Imaging / TIFF / BigTIFF Proposal|
AWare Systems on-line
The BigTIFF File Format Proposal
What is BigTIFF?
The TIFF file format uses 32bit offsets and, as such, is limited to 4 gigabytes. This has been quite sufficient for many years. Today however, there is a need for a good multi-purpose open image file format that can handle huge images, or very large collections of images, breaking the 4 gig boundary.
There is currently an ongoing attempt to launch a new variant of TIFF, called BigTIFF, that closely resembles TIFF, but uses 64bit offsets instead. The benefits of closely resembling TIFF are huge. For instance, existing TIFF libraries can quite easily extend their support for TIFF to also include this new variant. Documentation needs are minimal. All the much appreciated properties of a file format that has been around and has been extended for more then a decade are inherited. All properly known tags are being reused, all supported bitdepths and datatypes remain valid. The arbitrary number of 'extra channels', the tiling and striping schemes, the multitude of compression schemes, and the private tag scheme, that made TIFF very useful in pre-press as well as for storing scientific data, and many other applications, all remain intact. Yet, the offset bitdepth changes, and BigTIFF files are no longer restrained by the 4 gigabyte limitation from which classic TIFF suffers.
The purpose of this page is to present the details of the BigTIFF proposal, as it differs from TIFF. The bulk of this page is made to resemble the informal introduction to the highest level TIFF structures, as given in the TIFF File Format FAQ. If you are not yet familiar with this level of TIFF detail, you might want to take a look at that first.
Another source of information on the BigTIFF proposal is the BigTIFF design page over at the LibTiff site. That page is the HTML equivalent of a former Wiki format design working place. The Wiki was the authoritive page, and the working place. This page is more like an informal overview, instead, and bears no authority. There is also the LibTiff Mailing List Archive, where the format was born out of lengthy discussions. In the next overview of BigTIFF structures, a link entitled 'discussion' points to a particular thread in that archive. This discussion is most probably the final starting point of BigTIFF.
Whilst BigTIFF is not yet an actual official standard, there were quite a few people involved with developing the BigTIFF draft specification, including people from Adobe, and there have been no changes since that time. There are at least two independent implementations (our own AWare Systems AsTiff, and LibTiff since version 4.0). Furthermore, BigTIFF is a small and quite natural progression from TIFF. It seems highly unlikely that an organization with some apparent position of authority (i.e. a standards organization or Adobe) will produce a document on their own that contradicts this draft specification at this stage. We thus feel we can safely recommend adoption of BigTIFF now.
The proposed BigTIFF structures
Here's the classic TIFF file header...
And this is the new BigTIFF file header...
The last members in both variants of the structure point to the first IFD (Image File Directory). This IFD can be located anywhere in the file. Every 'page' in a multi-page TIFF, classic TIFF or BigTIFF, is represented by exactly one IFD. Here's a more detailed view of the classic IFD...
And this is how the IFD looks like in the new BigTIFF file format...
The tags in this IFD should be sorted by code, in both classic TIFF and BigTIFF. Every tag takes up exactly 12 bytes in classic TIFF, and looks like this...
This same tag structure, in BigTIFF, takes up 20 bytes, and looks like this...
The same rule for 'inlining' the tag data applies to both classic TIFF and BigTIFF, only the threshold size differs. In classic TIFF, the tag data was written inside the tag structure, in the IFD, if its size was smaller than or equal to 4 bytes. Otherwise, it's written elsewhere, and pointed to. In BigTIFF, the tag data is written inside the tag structure, in the IFD, if its size is smaller than or equal to 8 bytes.
Other miscellaneous details
Amongst the suggested file extensions are 'tif', 'tf8' and 'btf' (see discussion in the LibTiff mailing list).
Three datatypes are added to classic TIFF:
The StripOffsets, StripByteCounts, TileOffsets, and TileByteCounts tags are allowed to have the datatype TIFF_LONG8 in BigTIFF. Old datatypes TIFF_LONG, and TIFF_SHORT where allowed in the TIFF 6.0 specification, are still valid in BigTIFF, too.
Likewise, tags that point to other IFDs, like e.g. the SubIFDs tag, are now allowed to have the datatype TIFF_IFD8 in BigTIFF. Again, the old datatypes TIFF_IFD, and the hardly recommendable TIFF_LONG, are still valid, too.
BigTIFF example files
We've assembled a series of BigTIFF example files. Needless to say that there hasn't been much opportunity to cross-test these, yet. We've checked and double-checked, but there are no guarantees...