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

2012.04.27 15:35 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Charles Auer

The following tags are found in quad-jpeg.tif (AsTiffTagViewer 2.00, Aware Systems):ImageWidth (1 Short): 512ImageLength (1 Short): 384BitsPerSample (3 Short): 8, 8, 8Compression (1 Short): JPEG Technote #2Photometric (1 Short): YCbCrStripOffsets (24 Long): 8, 175, 342, 633, 2227, 3683, 5112, 6553,...SamplesPerPixel (1 Short): 3RowsPerStrip (1 Short): 16StripByteCounts (24 Long): 167, 167, 291, 1594, 1456, 1429, 1441, 1114,...PlanarConfig (1 Short): ContigXPosition (1 Rational): 0YPosition (1 Rational): 0JpegTables (574 Undefined): ReferenceBlackWhite (6 Rational): There is no YCbCrSubsampling tag present in this file. According to TIFF, Revision 6.0 (1992), the default values of this field are [ 2, 2 ].Charles

 > From: john.evans@mathworks.com
> To: tiff@lists.maptools.org
> Date: Tue, 24 Apr 2012 12:26:21 -0400
> Subject: [Tiff] YCbCr/JPEG issue in 4.0.1

I'm seeing an issue in 4.0.1 regarding jpeg-compressed YCbCr tiffs that wasn't present in 3.9.5. A 4.0.1 client such as tiffinfo doesn't seem to print out 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. "quad-jpeg.tif" is an example file where this happens.

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 :-)