AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home Imaging / TIFF / BigTIFF Proposal
AWare Systems on-line

Home
Custom development
Imaging
    TIFF
        TIFF File Format FAQ
        BigTIFF Proposal
        TIFF Tag Reference
        TIFF Tag Viewer
        LibTiff Mailing List Archive
        TIFF in Delphi
        TIFF Links
    Custom development
TechTalks
Company
Links

Languages

  English version
  Nederlandse versie

Contact

Information: info@awaresystems.be
Helpdesk: support@awaresystems.be
Sales: sales@awaresystems.be



Valid HTML 4.01!



The BigTIFF File Format Proposal

Index

What is BigTIFF?
The proposed BigTIFF structures
Other miscellaneous details
BigTIFF example files

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...

OffsetDatatypeValue
0WordByte order indication
2WordVersion number (always 42)
4Unsigned LongOffset to first IFD

And this is the new BigTIFF file header...

OffsetDatatypeValue
0WordByte order indication
2WordVersion number (always 43)
4WordBytesize of offsets
Always 8 in BigTIFF, it provides a nice way to move to 16byte pointers some day.
If there is some other value here, a reader should give up.
6WordAlways 0
If there is some other value here, a reader should give up.
8Unsigned 8ByteOffset to first IFD

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...

OffsetDatatypeValue
0WordNumber of tags in IFD
2+x*12Tag structureTag data
2+(number of tags in IFD)*12Unsigned LongOffset to next IFD, if there is a next IFD
0 otherwise

And this is how the IFD looks like in the new BigTIFF file format...

OffsetDatatypeValue
0Unsigned 8ByteNumber of tags in IFD
8+x*20Tag structureTag data
8+(number of tags in IFD)*20Unsigned 8ByteOffset to next IFD, if there is a next IFD
0 otherwise

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...

OffsetDatatypeValue
0WordTag identifying code
2WordDatatype of tag data
4Unsigned LongNumber of values
8x * Tag data datatype
or Unsigned Long offset
Tag data
or offset to tag data

This same tag structure, in BigTIFF, takes up 20 bytes, and looks like this...

OffsetDatatypeValue
0WordTag identifying code
2WordDatatype of tag data
4Unsigned 8Byte
Discussion of this member's datatype is now closed.
Number of values
12x * Tag data datatype
or Unsigned 8Byte offset
Tag data
or offset to tag data

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:
TIFF_LONG8 = 16, being unsigned 8byte integer
TIFF_SLONG8 = 17, being signed 8byte integer
TIFF_IFD8 = 18, being a new unsigned 8byte IFD offset.

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...

BigTIFF sample files BigTIFFSamples.zip contains a series of 8 different BigTIFF files. Especially note the BigTIFFSamples.html file in this zip, documenting their characteristics.