2009.12.11 16:15 "Re: [Tiff] YCbCr", by Antonio Scuri

As Joris pointed out, you actually get Y Cb and Cr planes. So the first component, that looks red, is infact Y, and indeed has the correct size. But the Cb and Cr planes are downsampled. At least this is what I got here.

I use libtiff 3.8.2. I have to comment the code at "tiff_jpeg.c" that does "downsampled_output = TRUE" and add "tif->tif_flags |= TIFF_UPSAMPLED;" so I got all YCbCr planes at normal resolution.

When I upgraded to libtiff 3.9.2 my code stop working. Now almost all the samples I have with YCbCr and JPEG compression fail to read. This includes the known quad-jpeg, smallliz and zackthecat.

It is the same for libjpeg6 or libjpeg7.

I have to investigate the changes between 3.8 and 3.9 to see if I'm not missing anything.

BTW, I do use TIFFReadScanline and TIFFReadTile to read the image data. I'm not using the high level functions.

Best,
scuri

> -----Original Message-----
> From: tiff-bounces@lists.maptools.org [mailto:tiff-
> bounces@lists.maptools.org] On Behalf Of Steve Mills

On Dec 10, 2009, at 14:21:08, Antonio Scuri wrote:

When loading YCbCr colorspace from JPEG compressed images I had a problem with the size of the returned images. The logic in "tiff_jpeg.c" returns a downsampled image. I fixed it changing the code so it returns a normal size image. Let me know if you are interested.

In what way was it downsamples? Can you give an example? The one test file I just tried looks like the correct size (it's an all red image). We're asking for the tags we're interested in and reading it row by row. Is this different from how you're loading tiff's?