2012.04.24 16:26 "[Tiff] YCbCr/JPEG issue in 4.0.1", by John Evans

2012.04.27 17:07 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Joris Van Damme

Charles,

According to TIFF, Revision 6.0 (1992), the default values of this field are

> [ 2, 2 ].

Your reasoning is correct, but doesn't take into account some added robustness in the decoder part of LibTiff that may result in auto-correct of tag value or auto-correction of default-valued absent tag value (pfwew).

Or maybe you got that. But I thought I'd add my take on the complete story when it comes to cumbersome tags like Subsampling. If that's redundant, please just ignore me.

Subsampling can be applied to any colorspace, in theory, but it only makes meaningful sense in colorspaces that have a first channel that is luminance or brightness or whatever, and two subsequent channels that combine to represent chromaticity. So it can be meaningfully applied to YCbCr and L*a*b*, for example.

Subsampling can be combined with any compression mode. It can be combined with flate compression, LZW compression, or JPEG compression, for example.

But there is a difference. Flate and LZW are sortoff 'ignorant'. The get raw data, and independent of meaning and ordering, they compress. Or they take raw compressed data, and decompress to raw data, independent of meaning and ordering. This is different for JPEG. JPEG compression 'knows' about channels, subsampling details, etc.

So, there's actually two places where subsampling specification is present, when combined with JPEG compression. It's in the subsampling tag value, but it's also inherently encoded in the JPEG compressed data.

Actually, there's three places, since the JPEG compressed data is preceded by some basic markers, one of which specified the subsampling value.

As always, when one single piece of information is redundantly encoded in different places, some people get it wrong, and there's files out there where the tag value and the JPEG markers contradict each other. The JPEG marker data rarely contradicts the JPEG compressed data, as this is usually done with one single codec, whilst the former two are usually done by one container codec and a sort-off plugged-in subcodec so it's a lot easier to get this wrong.

As always, that means decoder manufacturers are forced to build in some added robustness. In this case, LibTiff in particular auto-corrects the tag value so as to correctly reflect the JPEG marker, which does seem to be a good way to both read all legit files as well as a lot of files that are incorrect in this specific manner. As always, that's a mixed blessing. Various encoders are cross-tested by feeding their output to LibTiff, which means this particular encoder bug goes unnoticed, which eventually means there's even more incorrect files 'out there' and things go further downhill. But of course, there's not a lot of other options here, from the point of view of the LibTiff decoder maintainers.

Unfortunately, LibTiff's notion of 'tag value' is singular. It would have been better if it were dual, where one was a representation of the actual tag value, and the other the value after adding proper default values and auto-corrections and the like. This would have been more functional, as well as less confusing and fragile where values get auto-corrected and the auto-correction depends on other values that might or might not get auto-corrected, etc. But, that's just the way it is, and it does unavoidably result in breakage and maintenance nightmare every couple of version updates.

Revisiting the beginning of this explanation, things get even worse, actually. A lot of TIFF is 'interpolation' from the spec, because the spec sort-off gives 'base examples' in the form of crude catagories. Nowhere in the spec does it say you can encode 15bit grayscale, or 5-6-5 bit RGB, or 32-32-32 bit YCbCr. But we all agree you can. It's unambigious. Now, nowhere in the spec does it say subsampling can apply to L*a*b*. Can it? I think it can. But you might dissagree, in fact, there is some debate over this issue. And can subsampling apply to the colorspace 56, given the fact that none of us know what colorspace 56 is?

This would not be a problem if the default value for this tag was [1,1]. The absence of tag could then mean that subsampling didn't apply, as per encoder point of view, or either that the default subsampling value [1,1] was used, as per encoder choice, but both would amount to the same thing. Unfortunately, the default value is [2,2]. So both amount to something completely different. That leaves a mess from which there's simply no escape.

So, is the default [2,2]? Actually, even though the spec says so, 'subsampling does not apply to this colorspace' is equivalent to a subsampling value of [1,1], so even if we agree on the default value, our agreement is meaningless is we don't agree on what colorspaces can and cannot be subsampled...

Any encoder implementer reading this, I think it's highly recommended to regard only YCbCr and L*a*b* as colorspaces that can be subsampled, and **ALWAYS** add a subsampling tag even if you're applying default values. Double-check that you get the value wright when using JPEG compression, simple cross-testing will not confirm this. Any decoder implementer, I think it's highly recommended to always regard YCbCr as a colorspace that can be subsampled and use default values [2,2] if tag's missing, and optionally add auto-correction from JPEG compressed data as LibTiff attempts to do in unbroken versions, and regard L*a*b* as a colorspace that can be subsampled **IF AND ONLY IF** the subsampling tag value is present (which amounts to using default subsampling values [1,1] on L*a*b* data if that easier to implement since it yields the same result). This doesn't completely resolve the mess, but in practice it's the best option, leading to compatibility with the majority of files out there, and complete compatibility with anyone else following this recommendation.

Best regards,

Joris