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

2012.05.01 12:52 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Joris Van Damme

Charles,

For example, subsampling = [ 2, 2 ] data should look like this:

but instead you get this:

>
> OJPEG data are read correctly...

uncompressed and LZW compressed, and all of these

> images are read correctly

I haven't got the time to dive into LibTiff code, but I can make a guess as to what is going on that maybe can help point someone in the right direction.

Uncompression (is that a word?) and LZW compression both are ignorant of 'data organisation'. They take correctly organised subsampled data, compress, decompress, and return exactly the same. JPEG compression with LibJpeg is different, in that it does know about these things, and does expect subsampled data in a very particular data organisation. This organisation expected by LibJpeg compression, and returned by LibJpeg decompression, is different from the data organisation in TIFF/LibTiff. Thus, there is a need for conversion, in both directions. This conversion cannot be viewed as part of the normal TIFF pipeline, it is instead to be regarded as part of the decompression/compression step inside that pipeline. I think I remember I thus specifically wrote or rewrote it for the OJPEG subcodec.

Something similar ought to be present somewhere for the JPEG subcodec. I don't remember if we succeeded in centralizing it and reusing the same conversion code for both the JPEG and OJPEG subcodec, but that should certainly make sense.

If we did, the problem will likely reside in the conversion calling code in the JPEG subcodec. If not, the problem will probably be somewhere in the JPEG subcodec specific subsampling organisation conversion code.

Best regards,

Joris