A story of TIFF


02 Feb 2007

I'd like to tell a story. It's a sad story. It's a story about a file format called TIFF.

TIFF was developed in the mid 1980s, as an attempt to get desktop scanner vendors to agree on a common image file format, rather than each company have its own proprietary format. In the beginning, TIFF was a simple format. And TIFF did what it was supposed to do.

But time passed. Scanners became more powerful, and desktop computer disk space became more plentiful. And TIFF grew to accommodate grayscale images, then color images. TIFF grew to accommodate Postcript. Some vendors wanted vector drawings, so TIFF grew to accommodate that too. TIFF grew to include multiple images, and even foreign file formats like JPEG. TIFF grew outside just images, to include clipping paths, for cropping, along with frames, layers and pages. It seemed like everyone wanted their own special tag in the TIFF spec. It was a format of absolute, 100% perfect fidelity. If you could describe it, TIFF could do it. Heck, you can even specify your preferred byte ordering in TIFF!

Gone were the days of data loss. TIFF marked a new era of absolute, loss-less image perfection. Everyone would use TIFF, and fidelity would be perfect. 100% fidelity. Always.

But as TIFF grew, more and more vendors felt unable to support all of it. TIFF became unmanageable. Its number of options, staggering. That's when vendors decided to implement interoperability subsets. They would pick and choose which parts of TIFF were relevant to them, and ignore the others. Some vendors could not implement LZW compression, due to its patent restrictions, so they didn't. Some vendors saw no need to support Postscript or vector graphics. Other vendors only wanted Postscript or vector graphics.

Interoperability subsets was TIFF's downfall. The mismatch in TIFF support through out "TIFF compliant" applications is staggering. And today, the only TIFF file that you can make and expect to work elsewhere is an un-compressed raw-data TIFF.

Don't be a TIFF.