2009.12.10 18:28 "[Tiff] YCbCr", by Steve Mills

2009.12.12 02:37 "Re: [Tiff] YCbCr", by Antonio Scuri

My recommendation for you is to start at the TIFF format specification pdf. It has several interesting explanations that will answer some of your questions.

Anyway, here are some comments.

Yes there is no pre-defined conversion between CMYK and everything else. It really depends on how you should interpret the K component, and this usually involves the printer profile you are going to use.

Using libTIFF you can access images that are in the YCbCr color space in its raw state or with an automatic conversion to RGB. At least in the JPEG compression. The libtiff high level functions to load an RGB image do not use the automatic conversion, they load the image as YCbCr and then convert the raw data to RGB itself. By the way this is a recent change in libtiff.

Best Regards,

Antonio Scuri

From: tiff-bounces@lists.maptools.org [mailto:tiff-bounces@lists.maptools.org] On Behalf Of Gene Amtower
Sent: sexta-feira, 11 de dezembro de 2009 17:11
To: Steve Mills
Cc: tiff list
Subject: Re: [Tiff] YCbCr

Well, I was following this thread thinking I might learn something from the discussion, but somewhere along the way, it went off the tracks for me!

This last post confuses me because the original post mentioned that the TIFFTAG_PHOTOMETRIC tag was reporting YCbCr, where as this one suggests the image is in CMYK. Are we still talking about the original image from the first post? If so, why is there this apparent contradiction between the first and last post?

All of this info got me to reading on the web, and I see that YCbCr is a colorspace primarily used for signal transmission to reduce the amount of transmission bandwidth, hence the downsampling of the Cb and Cr components because they carry less data. Info on Wikipedia provides conversion formulas to/from RGB that depend on conversion factors that are not universal. From these formulas, a red pixel ends up generating a value in each of the Y, Cb, and Cr pixel values because "Y" carries the primary luminance info, while Cb and Cr only communicate a "difference" value for the Red and Blue components. It also suggested to me that you can't really view YCbCr values directly because they are calculated values used in data transmission that aren't directly related to the RGB world that we live in. From what I can tell, YCbCr and CMYK are completely different colorspaces for either signal transmission or printing (respectively), and converting from one to the other actually involves an intermediate pass through the RGB space, with both conversions involving variable formulas that depend on hardware-dependent and implementation-dependent mapping algorithms. It sounds like there is NO universal way to convert between these three representations. There's also the RGBA colorspace that includes transparency info in the Alpha A channel - does this impact YCbCr and CMYK representations at all, or is this impossible in these alternate colorspaces?

If anyone cares to enlighten me, can you help me understand this discussion on LibTiff handling of RGB, CMYK, and YCbCr without going into a long dissertation on images, color spaces, TVs, and printing processes? Is it possible to store YCbCr image data in a TIFF file? If so, are there mechanisms built into LibTiff to convert it automatically to RGB for viewing, or is that up to the primary application to perform necessary conversions to the viewable world? With the inherent variability of YCbCr color values, how would Steve even know if he was getting valid YCbCr data when reading the values from the image file?

I guess a quick summary of the colorspace capabilities in LibTiff and the Tiff standard in general would be really helpful to the uninitiated among us. I know there's a lot of vagueness in the TIFF standard, but explain as much as possible, please!

On Fri, 2009-12-11 at 10:58 -0