In the last couple of months, I’ve been talking quite a bit with Tim Waugh about color management of printers, and how to achieve working CM with CUPS. At the moment, gnome-color-manager locates CUPS devices and allows the user to calibrate them and assign profiles, but CUPS doesn’t actually use the assigned profiles for printing. Oops.
Needless to say, the combination of CUPS, ghostscript and other complicated little-known parts of the printing stack make this look almost impossible. OSX uses CUPS and CM works really well on printers using Apple products — and so it must be possible. We need to make it work on Linux too before Linux can become a serious option for artists and media professionals.
OSX uses a system-wide framework called ColorSync that does all the device<->profile mapping, and allows the user to change the ICC color profile for each device, and also allows the user to choose internal profiles listed in the printer definition file. ColorSync works really well, and is an integral piece of the OSX operating system.
GCM is a session process that provides session programs access to the per-user color management settings. Because GCM is running in the session it can integrate deeply into the GNOME desktop environment and is not particularly security sensitive. But, because the framework is per-session, system frameworks like CUPS cannot access the data, and we also have to rely on cludges like naming the display ICC file to be the same as the device ID and putting it in a well know location to be able to have a color corrected GDM screen. Urgh.
So, we need a trivial device<->profile daemon that works like a subset of ColorSync that the session GCM instances can use for defaults and also set profiles system wide for projects like CUPS. Over the Christmas holidays I wrote a small dameon called colord that provides a way for applications (or other daemons) to create, destroy and assign devices and profiles.
colord doesn’t do any file parsing or anything terribly unsafe, it’s just a simple system activated system DBus PolicyKit enabled daemon that has a simple database of devices that can reference specific profiles. Profiles are optionally assigned ICC profiles, and also have qualifiers that can be used to match them. For instance, a qualifier could be Epson.RGB.300dpi, which would match from the qualifier search of “Epson*”.
One thing to note: colord isn’t anything related to systemd. The name was chosen because colordaemon was too long to type and ColorManager and ColorKit names were already taken. It’s also intentionally techy, as users are not going to have to interact with colord whatsoever.
At the moment there is a test GTK application for developers and color geeks shipped in the colord package, but long term GCM is just going to use colord and all the configuration and settings will be done in the session by GCM itself.
Tim is working on the CUPS parts as I speak, and hopefully we can have something working in a few days. Exciting times.
8 thoughts on “colord”
Now this is where I would click on the “Flattr” button if there were one! Anyway, Kudos!!
Ohh, I do some of the Color Management stuff whilst working for Red Hat, but it’s very nice of you to ask. Thanks.
Thanks for working on this stuff! :D
If colord is “freedesktop enough?” I will be glad of implement the proper interface for KDE, in 1 month or so I will start to work hard on that area.
Thanks for all your work :)
The DBus interface is org.freedesktop.ColorManager :-)
If there is sufficient interest in colord and distros start shipping it then I’ll move it away from gitorious and create a project at freedesktop.org. If you start using colord, please email me if you have any patches / feedback / ideas and I’ll do my best. Thanks.
A session framework is not needed for the core of device to ICC profile association. The device and driver information association to ICC profiles should be completely separated from a per session hardware access. I understand per session rights are needed to talk to hardware, but its not needed for storing key/value pairs in a user data base.
Why did you not named it iccd ? Colord is really akward as a name.
On top of that, if the Dbus name is ColorManager, then it should be named ColorManager or Linux Color Manager ( lcmd ) or System ( Wide ? ) Color Manager
i don’t see how iccd is less awkward to colord. Color Manager would also have been a really bad name as it’s not actually managing color. It’s just a service that provides an interface color frameworks would find useful. The DBus name night have to be changed, but that’s no big deal.
Comments are closed.