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

2012.04.24 16:44 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Frank Warmerdam

John,

It sounds like you ought to file a ticket on this. It may be that the changed behavior is intentional. If the tag isn't really there but is deduced for processing it may be that it is not considered desirable to expose it as if it were really a tag.

On the other hand, this might well just be an unintentional side effect of other changes. Certainly this area is super fragile.

Does this break normal processing of the image? For instance does tiff2rgba fail?

Best regards,

On Tue, Apr 24, 2012 at 9:26 AM, John Evans <john.evans@mathworks.com> wrote:

I'm seeing an issue in 4.0.1 regarding jpeg-compressed YCbCr tiffs that wasn't present in 3.9.5. 4.0.1 client such as tiffinfo doesn't seem to print out   A the TIFFTAG_YCBCRSUBSAMPLING value on a tiff when the library has to "sniff out" the subsampling values from the JPEG datastream, whereas a 3.9.5-based tiffinfo does. is an example file where this happens.  "quad-jpeg.tif"

When digging deeper, the TIFFGetField library routine fails on the subsampling

> tag on quad-jpeg.tif in 4.0.1 whereas it succeeds in 3.9.5.  I've tried

debugging further, but I get a bit lost when the library code gets into the

> TIFFFieldSet macro, which is where TIFFGetField  is failing.  In 3.9.5, the

code looks like it would continue on into JPEGVGetField, but in 4.0.1 this function is missing the case for TIFFTAG_YCBCRSUBSAMPLING, which makes me think that I'm missing something blindingly obvious here?

I did NOT run the configure script in 4.0.1 with "--disable-check-ycbcr- subsampling" option :-)

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer