TIFF and LibTiff Mail List Archive


2005.09.30 07:16 "[Tiff] Baseline TIFF supported file formats", by Katrina Maramba
2005.09.30 11:36 "Re: [Tiff] Baseline TIFF supported file formats", by Joris Van Damme

2005.09.30 11:36 "Re: [Tiff] Baseline TIFF supported file formats", by Joris Van Damme


I need a list on the specific TIFF file formats when you have support for Baseline TIFF images. I cant find anything specific in the document TIFF 6.0.

Examples of TIFF file formats are: JPEG Baseline TIFF 24-bit RGB uncompressed interleaved

TIFF 24-bit YCbCr uncompressed interleaved

TIFF 24-bit RGB packbits interleaved TIFF 8-bit gray uncompressed/packbits

TIFF 8-bit palette color uncompressed/packbits TIFF 1-bit uncompressed/packbits/1D Huffman

What you call 'TIFF file formats', most of us usually call 'flavors', instead. There are a kazillion such flavors. Nobody every enumerated them or named them, nor is such really useful.

What you're doing seems like the 'brute force' road into TIFF decoding. You're building code that handles a specific flavor, a next specific flavor, etc. This is usually regarded unfeasable and useless because of the enourmous number of flavors that are possible, and the only slightly less enourmous number of flavors that are really 'out there'. Instead, usually, one wants to build a decoder that handles each issue seperately, and independently, such that all needed 'issue resolutions' can be combined to decode any specific flavor.

Here's an example. The first step in TIFF image data decoding (i.e. after you've made sense of the tags in such a way that you have convinient data structures describing the strip/tile positions and content and all), is resolving the fillorder issue. See also This step, if required, builds upon the step retrieving the data in the strip/tile. Its output should be ressemble the output of non-reversed strip/tile reading. That way, reversal of bitorder can be freely combined with next steps, whenever needed, and the number of 'flavors' supported multiplies by two.

The next step should be decompression. Again, there are a number of options. But the important thing is that the output of the 'uncompressed' decompression, 'flate' decompression, 'lzw' decompression, etc, should all be very similar. As such, it can be freely combined with fillorder on the 'previous step' end, and freely combined with whatever you need to do on the 'next step' end.

The next step should normally be the resolution of prediction. Again, make sure you've got good 'input' and 'output' protocols, and end up such that absence/presence of prediction is freely combinable with all compression flavors on the 'previous step' end, and all stuff you may want to do next on the 'next step' end.

The thing is, this way, you need to build yourself 1+10+1 blocks of code, to support 2*10*2 flavors, arbitrarilly assuming 10 compression modes are supported. 12 is feasible, 40 is not. And bringing all subsequent issues into the picture, the first number increases only slightly, and remains very feasible, the second number totally explodes.

You're not the first to make this mistake. Most people making that mistake sooner or later end up saying that TIFF is the acronym of 'Thousands of Incompatible File Formats', blaming the file format for their own lack of understanding thereof.

I believe Baseline TIFF supports the last four formats but I'm not sure about the first two. I think these are extensions..?? I need your confirmation.

Quite possibly. You have to remember that the TIFF 6.0 spec is over a decade old. At the time, the distinction between baseline and extension was meaningfull, and reflected presence or absence of broad support. These days, however, a lot of what was called 'extension' 10 years ago, is very widely supported by just about all readers out there. All stuff in your enumeration falls in the 'currently widely supported' category.

Joris Van Damme
Download your free TIFF tag viewer for windows here: