AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 2012

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2012.04.24 16:26 "YCbCr/JPEG issue in 4.0.1", by John Evans
2012.04.24 16:44 "Re: YCbCr/JPEG issue in 4.0.1", by Frank Warmerdam
2012.04.24 19:03 "Re: YCbCr/JPEG issue in 4.0.1", by John Evans
2012.04.24 19:19 "Re: YCbCr/JPEG issue in 4.0.1", by Even Rouault
2012.04.27 15:35 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.04.27 17:07 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.27 18:57 "Re: YCbCr/JPEG issue in 4.0.1", by John Evans
2012.04.28 01:58 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.05.02 09:51 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.05.03 21:58 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.28 09:28 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.28 09:46 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.28 15:10 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.04.28 16:26 "Re: =?windows-1256?q?YCbCr/JPEG_issue_in_4=2E0=2E1=FE?=", by Charles Auer
2012.05.01 12:52 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme

2012.04.27 17:07 "Re: 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