[Openicc] printer, driver, CUPS, PPD, printing GUI, ICC-profiles, colord, Oyranos, taxi....

[Michael Sweet]

On Jan 24, 2012, at 9:18 AM, Kai-Uwe Behrmann wrote:
> Am 18.01.12, 10:34 -0800 schrieb Michael Sweet:
>> On Jan 18, 2012, at 9:21 AM, Kai-Uwe Behrmann wrote:
> ...
>>> In the actual IPP standard she has no means to automatically associate the new calibration state for here alternative media and driver with the ICC profile. She wonders, why she must select all colour related options manually and hopes to have got it right.
>> 
>> No, her client software "uploads" the custom media type and profile to the printer along with the job ticket that was used to print the target image(s).  Later, her client software can query the printer to get the list of available profiles and media types - either she picks the profile and those job ticket attributes are chosen for her automatically (and not changeable?) or she picks the media type which causes the profile to be selected automatically.
> 
> Would you please elaborate about a practical detail in the example?
> As you wrote she printed the colour target on a roll, registred the new media type and uploaded the resulting profile with the job ticket. That is profile B on her printer.

Device profiles are not part of the job ticket, at least not as sent to the printer.

You *might* include a reference to one for the local printing system to use when converting the application-supplied content to the printer's device color space, but that is an internal implementation detail and not part of the protocol.

When communicating with the printer you send device color or calibrated color. For device color the only thing the device needs to know are the job ticket attributes and values associated with the color profile (typically things like color mode, resolution, media type, etc.) and not the color profile itself.

> Her printer now knows two ICC profiles with following schematic tickets:
> ICC Profile A {gamma=1.7 connection=wlan size=A4} // an earlier profile
> ICC Profile B {gamma=2.1 connection=usb size=A4}  // the new profile

This example is bogus from the start.  Connection is not a job ticket attribute. Gamma is questionable - see my prior posts on the subject. Size is almost certainly not something that would be critical to profile selection.

The "printer-icc-profiles" attribute contains a list of profiles with their associated names and job ticket attributes.  If the user wants to use a specific profile, the client UI then populates the corresponding options with the values needed to select that profile.  Or if the user wants to use an automatically-selected profile, the client UI just passes the options as chosen by the user and the printer will select the (best) matching profile based on the job ticket attributes supplied.

I am willing to propose adding a "profile-name" Job Template attribute to IPP so that a client can supply one of the "profile-name" values listed in the "printer-icc-profiles" attribute, and that specifying "profile-name" brings in all of the Job Template attributes included in the corresponding "printer-icc-profiles" entry. However, there are edge cases (what happens if the profile is removed between job submission and processing?) and I would personally prefer to see all of the Job Template attributes specified by the client to avoid ambiguity and to make the edge case processing easier.

> ...

> How does the CMS select the right calibration gamma?

The CMS doesn't.  The DEVICE PROFILE contains any calibration data needed to go from the PCS to the device color space.  The document contains the profile (or a reference) so that the CMS can convert document color to the PCS, and from there to device color using the device profile.

Gamma (as a user setting) is a crutch that CUPS provided (along with "brightness") to deal with the limitations of color management before ICC.  It isn't supported on the Mac and has been deprecated in CUPS for a while now - I think only the CUPS imagetoxxx filters support it these days...

There are far better ways to manipulate the apparent brightness, shadow detail, etc. of a photo in order to produce the best artistic rendition of that photo on paper.  Gamma, by itself, is a poor substitute and only encourages bad color management to proliferate.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair