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 17:34 "Re: YCbCr", by Toby Thain
On 12-Dec-09, at 11:37 AM, Gene Amtower wrote: > 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? Not really with respect to CMYK. TIFF is commonly used as an interchange format, e.g. from scanner to artist's computer. It is also commonly used as an archive/working format for print-oriented images. The actual interpretation of data is either by tacit agreement (e.g. "We assume SWOP inks, 20% dot gain") and corresponding program settings, or by embedded ICC profile. Software in print production has historically used both (specifically Quark XPress, InDesign, Photoshop, etc). Historically, CMYK workflows were based on passing through the scanned data without profile-based re-interpretation: – initial transparency scan in CMYK from a drum scanner with 'internal' tacit characteristics (e.g. UCR, dot gain) – transport to artist's computer – import to layout where an RGB proxy is generated – generation of PostScript separations referencing original CMYK scan (e.g. to film) – production of printing plates This workflow (typical during 1990s) would assume that the parameters and data of the original scan were correctly tuned for the end product – usually offset lithographic printing. It is also based on film photography. TIFF is ubiquitous in this workflow as given the software available at the time, it was the most efficient and reliable of the alternatives. Nowadays this flow would include profile based conversions and the original data is much more commonly non-CMYK digital data. Separation occurs late in the process, is done "on the fly", and would also involve a profile for the output device. So in a modern workflow there is in fact very little place for CMYK TIFF except when dealing with 'legacy' data. > > ... > > 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 In CMYK common usage would be existing archives of imagery intended for print (of which there must exist an enormous quantity in archives generated over the last 20 years). > 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. The CMYK would typically be generated by a "black box", for example a drum scanner. It is possible to characterise this by an ICC profile but this is not always done. But then RGB is not really different in this respect. --Toby > > 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/ > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/