2012.07.13 23:28 "[Tiff] Combinations of Predictor flags (Horizontal) with other TIFF tags", by Ryan Wong

2012.07.14 00:08 "Re: [Tiff] Combinations of Predictor flags (Horizontal) with other TIFF tags", by Joris Van Damme

Ryan,

Recently I encountered a TIFF image with LZW compression, Photometric Palette, and Horizontal Predictor. This image got trapped in a Tiff tag cleanup tool, which stripped off the Predictor tag and rendered the result illegible.

In general, the trick with TIFF is to *not* try and support combinations of stuff. The number of combinations is simply too big. You'll end up thinking TIFF is "Thousands of Incompatible File Formats". Or "stripping of the Predictor tag". ;-)

The trick is to instead view the separate steps in the encoding and decoding process, and try to keep 'm independent of each other. This way, prediction is just one of the steps, and it can be combined with whatever compression mode or colorspace.

Of course, whilst the latter thinking is most productive both in maintaining a clean and relatively simple codec with not too much hacks, on the one hand, and supporting just about any TIFF on the other hand, there are a few exceptions where some combinations are entirely possible but rather nonsensical, and a very few are entirely impossible and have to be trapped.

Combination of a palette colorspace and a predictor, clearly falls into the category of 'entirely possible but rather nonsensicale'. Still, that *is* entirely possible. One could try and avoid this combination in an encoder, or better still one could try and avoid the possibility in the application layer calling the encoder. But it should still be supported in the decoder. A good decoder, separating all individual independent steps, would be supporting it by... not even being aware of it, it needs nothing special.

 * What colorspaces (photometric interpretation) is it compatible with?

Prediction is entirely independent of photometric interpretation. If predication can be applied to the datatypes, it can be applied, whether photometric is RGB, Lab, or the unknown photometric 4369 that nobody knows off and might be a thing of the future or somebody's current private extension.

 * Is it valid for TIFF JPEG? If so, does it apply to the RGB values or the  YCbCr values?

Compression is entirely independent of photometric interpretation. Meaning, JPEG compressor should not even know what colorspace it's dealing with. Even if the hacky design of LibTiff in this regard seems to contradict this. Meaning, what is inside the TIFF, is what the Photometric says. If the Photometric says it's YCbCr, and there's prediction, then that's that. The Photometric might say it's RGB, even if the compression is JPEG, and then it is RGB, and prediction is applied to RGB values.

This being said, the combination of JPEG compression and prediction, in my humble opinion, is one of those very few combinations that ought to be viewed as entirely impossible and have to be specifically trapped.

theoretical technologists

The distinction between "theoretical technologing" and good programming is non-existent in this case. The easiest way to support TIFF, is by separating the process in independent steps. That also leads to the largest possible number of combinations inside the collection of supported TIFF. And it also leads to the cleanest possible code. So there's no image example that a theoretical technologist might come up with, that goes unsupported by a good programmer, in this case.

Best regards,

Joris Van Damme
AWare Systems