LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
December 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.12.11 19:11 "Re: YCbCr", by Gene Amtower
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! Thanks, Gene On Fri, 2009-12-11 at 10:58 -0600, Steve Mills wrote: > On Dec 11, 2009, at 10:15:39, Antonio Scuri wrote: > > > 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. > > What if the file is jpeg-compressed cmyk? The TIFFTAG_PHOTOMETRIC tag says > it's cmyk, not YCbCr. I expect cmyk data in this case, but it sure doesn't > look correct. > > _________________________________________________________ > Steve Mills Me: 952-401-6255 > Senior Software Architect MultiAd > smills@multiad.com www.multi-ad.com > > > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/