- 2012.04.24 16:44 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Frank Warmerdam
- 2012.04.27 15:35 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.04.28 15:10 "RE: [Tiff] YCbCr/JPEG issue in 4.0.1", by Charles Auer
Joris: Well, back to the bug reading JPEG (compression = 6) compressed images using Libtiff 4.0, the problem is only evident if you read the subsampled YCbCr data directly, doing resampling and color conversion yourself.
For example, subsampling = [ 2, 2 ] data should look like this:
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb
Cr
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb
Cr
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb
Cr
but instead you get this:
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb
Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb
Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb
Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
You can still recover the image by ignoring the zeroes and the error message.
As a matter of interest, Joris, OJPEG (compression = 7) data are read correctly. Rewriting tif_ojpeg.c was
a tremendous contribution that you made to Libtiff, by the way. Also, I made a set of YCbCr test images with all possible subsampling values ( [ 1, 1 ], [ 1, 2 ], [ 1, 4 ], [ 2, 1 ], [ 2, 2 ], [2, 4 ], [ 4, 1 ], [ 4, 2 ], and [ 4, 4 ] ), both uncompressed and LZW compressed, and all of these images are read correctly. The problem appears isolated to JPEG (compression = 6) compressed images.
The easiest work-around right now to handle JPEG compressed images with Libtiff 4.0 is either:
- Use TIFFReadRGBAImage
- Use TIFFReadEncodedStrip or
TIFFReadEncodedTile with JPEGCOLORMODE = 1
Of course, both of these methods output RGB colors.
Charles
> Date: Sat, 28 Apr 2012 11:46:15 +0200
> Subject: Re: [Tiff] YCbCr/JPEG issue in 4.0.1
> From: info@awaresystems.be
> To: bumble731@msn.com
> CC: john.evans@mathworks.com; tiff@lists.maptools.org