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