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.12 16:37 "Re: YCbCr", by Gene Amtower
So, you can store either RGB, YCbCr, or CMYK data in TIFF files. However, due to the variable conversion algorithms used for converting to/from CMYK or YCbCr, anything other than RGB is probably not likely to work outside of whatever application creates them. Is that a correct statement? Also, if a user employs the automatic conversion process to get from YCbCr to RGB, doesn't the wide variety of possible conversion matrices for this process make the automatic conversion somewhat inconsistent or even incorrect in some cases? Does LibTiff implement the most common conversion matrix (if that's even clearly defined) for this automatic process, or is there some guess at a conversion matrix based on the data itself? It just seems to me that storing image data in anything other than RGB- based formats is not a good idea for most general usages and should only be employed if the images are used for internal program processing only. Otherwise, the matrix employed to generate the YCbCr or CMYK format is not known to a reader of the file. Am I on the right track, or does LibTiff provide some means to communicate the conversion matrix to any other program reading the TIFF file? Thanks, Gene On Sat, 2009-12-12 at 00:37 -0200, Antonio Scuri wrote: > 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! > > 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/