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

2012.04.28 01:58 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Charles Auer

Hi John:I am able to reproduce the problems you describe. I am using Libtiff 4.0 (built from CVS, most recently on 12 March 2012) for files with JPEG compression (compression = 7), and I am also using TIFFReadEncodedStrip or TIFFReadEncodedTile to read the image data. 1. When both the horizontal and vertical subsampling factors equal 2, each row of image data is followed by a series of ((3 * image_width) / 2) or ((3 * tile_width) / 2) zeroes. 2. Every other tile fails to read at all, giving the error message “application buffer not large enough for all data."I am still able to recover the image by:1. Ignoring each series of zeroes. I advance the pointer by ((3 * image_width) / 2) after reading each line of a strip or by ((3 * tile_width) / 2) after reading each line of a tile.2. Ignoring the “application buffer not large enough for all data" error in tif_jpeg.c. I just change the following lines in tif_jpeg.c to a comment:if /( cc < sp->bytesperline * sp->v_sampling ) {TIFFErrorExt(tif->tif_clientdata, "JPEGDecodeRaw","application buffer not large enough for all data.");return 0;}--------------------I tried other YCbCr subsampling values. [ 1, 1 ] works fine, but [ 2, 1 ] produces the same problems.I also tried processing JPEG (compression = 7) images with planar configuration = 2. Luma strips and tiles are always read correctly. Chroma strips and tiles are read incorrectly, but again the images can be recovered by ignoring the extra zeroes and disabling the error exit in tif_jpeg.c, as shown above.--------------------These errors only occur with YCbCr subsampled JPEG compressed (compression = 7) images. Image data are read correctly for YCbCr subsampled OJPEG (compression = 6) images or for any other YCbCr subsampled images that I tried, either compressed any other way (such as LZW) or uncompressed.Again, as you report, TIFFReadRGBAImage reads the image data correctly.Also, YCbCr subsampled JPEG compressed (compression = 7) images are read correctly by TIFFReadEncodedStrip or TIFFReadEncodedTile when JPEGCOLORMODE = 1. I suspect that this is why I had not noticed this problem in the past. Yes, I confess, I am one of those lazy JPEGCOLORMODE = 1 people.Charles

 > From: john.evans@mathworks.com
> To: tiff@lists.maptools.org

Here's one more twist on this issue. I created a variant of quad-tile.tif to use jpeg compression instead, and the YCbCr subsampling coefficients are definitely there, as verified by tiffdump

Example file at http://mexcdf.sourceforge.net/quad-tile.jpg.tif

<snip>

ImageWidth (256) SHORT (3) 1<512>
ImageLength (257) SHORT (3) 1<384>
BitsPerSample (258) SHORT (3) 3<8 8 8>
Compression (259) SHORT (3) 1<7>
Photometric (262) SHORT (3) 1<6>
SamplesPerPixel (277) SHORT (3) 1<3>
PlanarConfig (284) SHORT (3) 1<1>
TileWidth (322) SHORT (3) 1<128>
TileLength (323) SHORT (3) 1<128>
TileOffsets (324) LONG (4) 12<8 1758 3804 6087 8087 9790 11721 13956 16170
18127 20290 22772>
TileByteCounts (325) LONG (4) 12<1750 2046 2283 2000 1703 1931 2235 2214 1957
2163 2482 1912>
SampleFormat (339) SHORT (3) 3<1 1 1>

JPEGTables (347) UNDEFINED (7) 574<0xff 0xd8 0xff 0xdb 00 0x43 00 0x8 0x6 0x6 0x7 0x6 0x5 0x8 0x7 0x7 0x7 0x9 0x9 0x8 0xa 0xc 0x14 0xd ...> YCbCrSubsampling (530) SHORT (3) 2<2 2>

</snip>

The file can be found at http://mexcdf.sourceforge.net/quad-tile.jpg.tif

As reported before, the RGBA interface reads the TIFF just fine (on both 3.9.5 and 4.0.1), but TIFFReadEncodedTile reports different results on 3.9.5 and 4.0.1. The first three YCbCr "clumps" running down the left hand side of the tile as reported by 3.9.5 are as follows (sorry for any bad spacing)

>     clump  0:   0   0    2  0  138  1