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

2009.12.12 17:34 "Re: [Tiff] 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?

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 w