[Openicc] Print Color Pipeline

[Richard Hughes]

On 24 January 2011 15:03, Jan-Peter Homann <homann at colormanagement.de> wrote:
> It is technically possible, that the printer driver tells colord, which
> profile is valid for a setting, and  the user has not to configure , the
> profile  in colord?

Correct. The printer "driver" can create a profile with a pre-set
qualifier, so a profile would only match "300dpi" or "plain-paper" and
that kind of thing. At the moment a profile can only have one
qualifier, but that's a purely artificial limitation.

> as I´m not a developer, I hade the impression, that this XML-file describes
> mostly different driving settings in a standardized format and also which
> ICC-profile is actually assigned to the device / setting.

That xml describes the interface exposed by colord to the world,
designed to be used by stuff in the system like CUPS and stuff in the
session like GCM. There's also no reason Oyranos couldn't connect to
colord too, although it would have to grow a DBus dependency.

> From my point of view, the part of assigning an ICC-profile to a printer
> driver setting could be handled internally in the printer driver and may
> don´t needs an external database with detailed driver settings

Agreed. The only thing colord is currently storing is any permanent
profiles and devices (e.g. virtual devices, although should be
uncommon) and the mapping between a profile ID to a device ID.

> Lets assume, the printer driver will be delivered with canned profiled and
> the user is forced to create (named/serialized settings/queues) like e.g.
>
> 1) plainpaper-draft
> 2) plainpaper-high-quality
> 3) mattpaper-high-quality
> 4) Photopaper-best-quality

Well, if they are supplied then the printer driver can set them itself.

> Is it correct, that now the printer driver should create for every queue a
> "Gnome ColorManager Device ID" and deliver the canned ICC-profile for this
> setting / queue also to colord, where it is imported in mapping.db and
> storage.db

The icc profile is optional, but that's basically how it works. That's
what we've done on the icc branch of cups.

> If now the user push the print button for a predefined setting, The Gnome
> Color Manager gets a signal with the DeviceID and delivers the correct
> Device Profile to the appplication / service which renders the print data to
> color managed bytemap for the printer driver.

Right.

> At printer driver level, there is no colorconversion involved (only
> screening and applying internal 1D LUT calibration curves, ink limites per
> channel and so (predefined from driver vendor for this setting)
> Colormanagement of application data for monnitor or print out would be
> pretty similar from the standpoint of the application which sends data to
> the monitor or to the printout.

I guess.

> Now, the user  wants for his preferred photopaper his own profile.
> In the driver, he changes the queue settings for "Photopaper-best-quality"
> by activating the Option "Testchart-Printing". By activating this option the
> driver sends "ProfilingInhibit" to colord.
> If the testchart will be printed, the Gnome Color Manager tells the
> application / service which renders the data for printout not to apply any
> color conversion.

Exactly. ProfilingInhibit is only really designed to be used when
printing test charts and when measuring the screen to create a
profile.

> The user measures the testchart or sends it to a profiling service and gets
> an ICC-profile for "Photopaper-best-quality" back. Now the user activates
> the driver Option "Install new profile" for the setting / queue. If the user
> is doing this, he imports the profile and the driver sends to colord an
> information that the profile in the mapping.db has to be updated for this
> setting / queue.

At the moment, I've got gnome-color-manager to just add the newly
created profile to the device, with the qualifier "*" and marked as
default. If we know it's photopaper, best quality black then we can
set the qualifier to something sane rather than "*".

> Optional, during the installing process of the ICC-profile, a additional tag
> will be added to the ICC-profile describing the driver setting.

Yes, although g-p-m doesn't do this yet. It could quite easily.

> - Could the described workflows be realized with colord ?

I think so.

> - Are there any applications, which already make use of the Gnome Color
> Management for rendering both to the monitor and the printout ?

Well, GCM is kinda an implementation detail. Really, programs like
inkscape should be talking to X11 and the session print driver stack,
which is typically XOrg and GTK+/Qt these days.

GCM is really just a session policy agent and a UI for changing the
mappings in colord. This pushes a lot of the "create" logic into
projects like CUPS, but I think that's a good thing on the whole.

Richard.