[cairo] Subtractive API, part 0

[Chris Murphy]

On Feb 2, 2010, at 3:56 PM, ecir hana wrote:

> On Mon, Feb 1, 2010 at 4:38 PM, Chris Murphy <lists at colorremedies.com> wrote:
> 
>> I follow this up to this point. There is always a "right" ICC profile for the source space.
> 
> Where you get the profile from? The manufacturer?

It depends on the originating application for the image/vector content. Ideally this would be some kind of well behaved RGB editing space, such as sRGB, Adobe RGB (1998), ECI-RGB 1.0, or possibly ProPhotoRGB. For CMYK there are a number of standard characterization data sets that can apply to CMYK original content.

> 
>> And there is a rather constrained range of "right" ICC profiles for the destination output process.
> 
> Where you get the profile from? A measurement? "constrained" and
> "right" seems to be an oxymoron.

If you're printing to a press in the U.S. there are only a handful of standard characterzations: SNAP for newsprint, SWOP TR 003 for #3 sheet web offset printing, SWOP TR 005 for #5 sheet web offset printing, GRACOL TR 006 for #1/#2 sheet. All are assumed to use ISO 2846 inks. If the actual printing condition doesn't conform to some existing standard characterization, then the printing company needs to accept responsibility for the fact their press is unique, and have a set of ICC output device profiles produced for their press conditions.

> 
>> I don't understand the characterization "that the numbers of possible ICCs grows
>> exponentially". That statement doesn't make sense.
> 
> A printed color is affected by multiple things: paper, ink, dot gain,
> ... I would expect that for every combination there should be a
> profile. All the possibilities form a tree, hence the exponential
> growth in size.

Most printing companies print with nearly the same aimpoints for all papers of the same quality type, thus only one profile is needed unless the white point of the paper is dramatically different. Most printing companies print on a narrow range of paper types.

> 
>> Generic conversions to output space will result in generic output that will often require an
>> iterative proof-correction cycle to fine tune the result. Had you had the correct source
>> (likely) and correct destination (less likely) profiles, then the color separation would have
>> been made for the output condition, and you'd have extremely good correlation to what you
>> wanted in the first place.
> 
> Again, where can I get a destination profile for some random printer
> and random paper? And how could I get possibly good result if I don't
> have the right destination profile? From that costly iterative cycle?

Ask the printing company. If they can't supply an appropriate recommendation then yes it's going to fall back on a traditional (and costly) iterative proof+color correction cycle. That's just how it works. If you want something closer then you need good process control for the press so it's consistent, and then you need an ICC profile built from actual press behavior, so that the unique press behavior can be accounted for when converting from RGB to CMYK, but also for the proofing system which will use the same profile to go from CMYK to CMYK' (for the proofing system which uses a completely different inkset and media than the press).

> 
> On the other hand, if I knew the paper was uncoated and soaked too
> much ink, I could increase dot gain compensation and decrease ink
> coverage. This is what I meant by "experience" - be it yours (even as
> content creator) or that old guy at the company who is printing 30
> years.

Dot gain and ink limits are a function of ICC profiles. This is not done manually in any modern printing or prepress or publishing I've been to in almost 10 years; it depends on ICC profiles. Specifically the 'output device class'.


Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"