TIFF is a very popular image format, but it can’t handle really huge files. “Really huge” means files bigger than 4 gigabytes, or more precisely, files in which any data offset can’t be represented in 32 bits. That’s not a limitation that comes up often, but some applications, such as medical scans, need enough detail to push the limit.
A dozen years ago, members of the TIFF community at AWare Systems came up with a simple idea: Create a variant of TIFF with 64-bit offsets instead of 32 bits. The result was BigTIFF.
It’s never caught on in a big way, though. The Library of Congress recognizes it, citing its “excellent support for images with very high spatial resolution.” Its list of sustainability factors for BigTIFF shows a sparse list of applications that support it, though.
The biggest factor in BigTIFF’s favor is that the widely used LibTiff library supports it. This means there are probably lots of applications that could support it with a small amount of effort. There just hasn’t been enough interest for them to do it.
Personally, I think BigTIFF has suffered from an identity problem. Is it TIFF or not? Adobe Systems holds the copyright to the TIFF specification and the TIFF trademark. While Adobe hasn’t used its trademark power to veto BigTIFF the way it did with TIFF/A, it also hasn’t recognized BigTIFF as part of TIFF. The TIFF spec remains unchanged since 1992, though there have been some important technical notes since then. Adobe’s software offers very limited support for BigTIFF.
On strictly technical grounds, BigTIFF isn’t TIFF. Any software that looks for the magic number 42 in bytes 2-3 won’t find it. The change in the tag structure is programmatically simple but incompatible.
Maybe BigTIFF would have done better if its creators had promoted it as a new format. It could have filled a useful niche as a large file format with all the features of TIFF. As it stands, it’s a rather risky format for long-term use.