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

[Michael Sweet]

On Jan 17, 2012, at 3:22 AM, Kai-Uwe Behrmann wrote:
> Mike,
> 
> first of all thanks for the detailed explanations. It helped a lot while reading the spec. My comments are below ...
> ...
> How does the profile selection work react on user edited options like gamma, brigthness ...
> In JPS3 I found only the: 5.6.22 printer-icc-profiles (1setOf collection)

OK, so long long ago there was a "color" spec that was worked on in the PWG but later abandoned that addressed user options like gamma and brightness.  We looked at importing those into JPS3 but ultimately decided against it since they break color management (or rather, they make the assumption that color management isn't working properly).

Applications can make modifications to an image before printing for artistic or esthetic purposes, and that is where we see "gamma" and "brightness" living.

>> Printers can also advertise a list of rendering intents (the usual ICC stuff plus relative BPC) so that the client knows how those profiles will be applied during printing.  The client can specify which of those intents to use for a given job in the job ticket.
> 
> That looks good to me. Great to see "relative-bpc".
> 
>> These attributes allow the client to do soft-proofing (for example, in the print preview window/dialog of a client UI) and client-side color management (if you don't like the printer's CMS but do like its profiles).
> 
> These are all good things for useability. How does the spec adress your
> considerations, which prevented to expose printer profiles in CUPS? (http://www.cups.org/str.php?L2894)

The problem with exposing PPD-registered ICC profiles in a secure way is a CUPS implementation issue, not a protocol issue.  CUPS has to collect all of the ICC profiles from multiple sources and then provide a mapping specific to that printer - we don't just want to allow access to all files on the system.

Profiles advertised by a printer in the printer-icc-profiles attribute can be printer-resident or served by a separate server.

>> If you want to use a custom profile (or if you are doing client-side color management), you just supply document data using a device colorspace (e.g. DeviceGray, DeviceRGB, DeviceCMYK, etc. for PDF or PostScript).
> 
> How does that interact with all of the legacy /DeviceRGB content? Specifically: will that new behaviour become a hard cut? Will the filters make a difference for device colour spaces depending on old style PPD API usage in CUPS and new IPP style submission?

Again, let's separate IPP Everywhere from CUPS.

IPP Everywhere says nothing about how a printer should interpret color values in a particular file format - that is up to the definition/specification for the file format, and there are sufficient standards (particularly for PDF and PWG Raster) on how to do device color.

For CUPS, the ultimate path will eliminate (or at least greatly reduce) the use of filters on the system - a printer that accepts PDF and implements the minimum set of IPP Job Template attributes needs no filter.  A printer that accepts PWG Raster needs a PDF RIP filter to generate PWG Raster from PDF.  For legacy PPD queues, we will advertise and register profiles as needed, but it is up to the filters to honor the color management intent of the user (or at least as much as the printer driver developer allows it to...)

> My personal preference is to make a hard cut in not colour converting Device colour spaces and allow this way easier client side colour management, including relyable profile creation.

That is something you'll need to work on in the Linux/Open Printing space.  CUPS doesn't care - the filters do all of the CM work.

> Can you confirm, this mechanism is only useful for PDF/PS? Jpeg, PNG and SVG have no means to mark colours as being in device space?

JPEG allows for grayscale, RGB, and CMYK that are not tagged with a color space or profile.  The implementation advice is typically to use sRGB for grayscale and RGB by default, but there is no default CMYK space.

PNG and SVG are targeted at calibrated color spaces (SVG specifically uses sRGB), although PNG does allow you to embed ICC color profiles.

> I asusme the PDF OutputIntent together with PDF/X/A/E will still work.

Like I said above, IPP Everywhere doesn't define how to do device color for format X. It just provides the basic profile and rendering intent information needed for a client to soft-proof and/or do client-side color management with the saved color profiles.

>> If you want the printer to automatically use a custom ICC profile, the client sends a request to the printer (Set-Printer-Attributes) with the updated list of printer-icc-profiles-supported values.  That list becomes available to all clients of that printer...
> 
> Thats a great addition.
> 
>> Please let me know if the model we are using in JPS3 is not sufficient (and specifically why) as soon as possible since we are trying to lock down the technical changes for JPS3 for a working group last call in the coming month...
> 
> We like similiar mechanism like the PPD ColorKeyWords:
> http://www.freedesktop.org/wiki/OpenIcc#PPD_colouring
> A keyword like "print-color-keywords" should contain the names of those keywords, which are influental to colour like: media, resolution, brightness, gamma ...  Contrary, paper size is not colour related.
> These informations are needed during profile creation and allow automated profile selection.

This is part of the collection attribute value - each profile may use a different set of attributes and associated values, so any additional attribute would have to list the superset of all attributes.

There is another issue with a simple list of keywords - the "media-col" attribute is used to do complex (modern) media selection based on characteristics such as media color, type, tooth, grain, etc.  It would not be sufficient to list "media-col" in your proposed attribute since we really want the member attributes, not media-col itself.

> Having that keyword described inside JPS will cover the ICC requirements more completely. Please correct:
> 
> 5.6.33 printer-color-attributes (1setOf type2 keyword)
> The  RECOMMENDED "printer-color-attributes" Printer attribute lists all color related operation attributes that are influental to color appearance.
> 
> You mentioned a similiar to cupsICCProfile qualifier attribute, but I could not find it in JPS3.

The printer-icc-profiles attribute is a set (list) of collections, each of which includes the profile URL and the attributes (qualifiers) and associated values that will cause that profile to be selected.

The following PPD usage:

    *cupsICCQualifier1: ColorModel
    *cupsICCQualifier2: Resolution
    *cupsICCQualifier3: MediaType
    *cupsICCProfile Gray.360dpi./Draft Grayscale: "/path/to/gray-360.icc"
    *cupsICCProfile RGB.360dpi./Draft Color: "/path/to/rgb-360.icc"
    *cupsICCProfile RGB.720dpi.Glossy/Glossy Color: "/path/to/rgb-720-glossy.icc"
    *cupsICCProfile Gray.720dpi.Matte/Matte Grayscale: "/path/to/gray-720-matte.icc"
    *cupsICCProfile RGB.720dpi.Matte/Matte Color: "/path/to/rgb-720-matte.icc"

would map to the following printer-icc-profiles values in IPP:

    { profile-name='Draft Grayscale' profile-uri='http://www.example.com/gray-360.icc' print-color-mode='monochrome' printer-resolution=360dpi }

    { profile-name='Draft Color' profile-uri='http://www.example.com/rgb-360.icc' print-color-mode='color' printer-resolution=360dpi }

    { profile-name='Glossy Color' profile-uri='http://www.example.com/rgb-720-glossy.icc' print-color-mode='color' printer-resolution=720dpi media-col={media-type='photographic-glossy'} }

    { profile-name='Matte Grayscale' profile-uri='http://www.example.com/gray-720-matte.icc' print-color-mode='monochrome' printer-resolution=720dpi media-col={media-type='photographic-matte'} }

    { profile-name='Matte Color' profile-uri='http://www.example.com/rgb-720-matte.icc' print-color-mode='color' printer-resolution=720dpi media-col={media-type='photographic-matte'} }

 
__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair