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
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2012.04.28 01:58 "Re: 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
> Date: Fri, 27 Apr 2012 14:57:33 -0400
> Subject: Re: [Tiff] YCbCr/JPEG issue in 4.0.1
>
> 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 139
> clump 32: 0 0 9 6 134 119
> clump 64: 44 40 63 59 230 95
>
> but 4.0.1 reports
>
> clump 0: 0 0 2 0 138 139
> clump 32: 0 0 0 0 0 0
> clump 64: 0 0 9 6 134 119
>
> and one can see the effect when the tile is visualized, that two rows of
> zeros
> are interspersed amonst each two valid rows of luminence pixels, and that
> a
> row of zeros is interspersed in between the valid rows of chrominence
> pixels.
>
> The last thing is that a 4.0.1 client reports the "JPEGDecodeRaw:
> application
> buffer not large enough for all data" warning during the call to
> TIFFReadEncodedTile and returns a -1. A 3.9.5 client reports all ok,
> though.
>
> If no objections, I'll file a bug report?
>
>
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/
