2005.05.25 09:52 "[Tiff] How to Write a tif file with compression = COMPRESSION_JPEG & photometric = PHOTOMETRIC_YCBCR ?", by Kelvin Zhong

2005.05.26 14:10 "Re: [Tiff] How to Write a tif file with compression =COMPRESSION_JPEG & photometric = PHOTOMETRIC_YCBCR ?", by Jean-Yves Le Ridant


I've seen JPEG-in-TIFF, with Photometric indicating YCbCr, and SamplesPerPixel=1. The JPEG data, in this case, had a single channel, as expected. The results when interpreting this channel as the Y component of YCbCr were fine.

I've also seen TIFFs with Photometric indicating L*a*b*, and SamplesPerPixel=1. The single channel, interpreted as the L* component of L*a*b*, made perfect sense, visually.

In my humble opinion, if a multichannel colorspace start with a brightness channel, and the SamplesPerPixel value equals 1, that is a unambigious situation, and may be preferable over storing grayscale as full YCbCr.

Yes, but do this conform to TIFF specifications?

Using MinIsBlack or MinIsWhite photometrics, and JPEG-compressed single-channel data, may indeed also be an option...

Jpeg compression of palette color indexes would be as strange idea as jpeg compression of CIELAB. And it is out of spec.

However, I've seen jpeg compression of CIE L*a*b*, and to me that *does* make perfect sense. L*a*b* is a colorspace with a brightness channel and two chroma channels, just like YCbCr. But there's good reason to assume L*a*b* is more perceptually uniform compared to YCbCr, so that actually makes it technically *more* suitable to be used as input for the JPEG compression algorithm... There is also ITULAB, a color-fax oriented standard for encoding L*a*b* in JPEG (and in JPEG-in-TIFF).

I agree that LABs colorspace could be seen as "the" colorspace for jpeg compression, and ICCLAB and/or ITULAB are perfect. The problem is with tif's PHOTOMETRIC_CIELAB continous tones *signed* representation which are, for now, without special case, traited as unsigned value by jpeg compressor/decompressor. A slight "2 or 3" difference around "128" unsigned values, can cause at the end, a differences like +/- 125 in signed vals.