[Openicc] colord 0.1.0 released!

Richard Hughes hughsient at gmail.com
Mon Jan 17 01:38:49 PST 2011


On 17 January 2011 02:48, Robert Krawitz <rlk at alum.mit.edu> wrote:
> 1) From the Gutenprint perspective, it's very important to be able to
>   turn this off selectively (for the purposes of profiling, if
>   nothing else).  The inability to turn off ColorSync has been a
>   major thorn in the side of a lot of our Mac users, and is actually
>   impeding progress in regards creating a color managed workflow with
>   Gutenprint on that platform.

Yes agreed. gnome-color-manager will have to be able to turn this off
for profiling too, and I admit there isn't a dedicated method for
doing this just yet. It's pretty easy to remove all the profiles for a
device, but then you have to trust the profiler to add them all back
again after profiling :-)

There'll likely be some sort of inhibit interface for the
GetProfilesForQualifier method call. Ideas welcome.

> 2) High bit depth capability is essential, at least downstream of
>   colord.  Both CUPS and Gutenprint can handle 16 bits just fine, but
>   it's important that the transformation not lose information from
>   the data provided by the user.

I'm quite keen on having colord stay away from pixel manipulation. I
think that's much better placed in the driver itself, using something
like lcms. Colord should concentrate on being a smart storage unit
that can be queried by CUPS for specific bits of data.

> 3) Is there any provision for DeviceN profiles?  I'd like to see
>   DeviceN input for extended color printers (such as the Epson

Sure, at the moment CUPS adds a DeiceN profile for my HP Photosmart
printer, I see no reason not to expose that in colord.

> 4) Finally (and this is personal, not Gutenprint-related), will any of
>   this work under KDE (at least the printing stuff, since GNOME won't
>   be running)?

colord doesn't need gnome. There's a command line tool called colormgr
that allows you to add devices, delete profiles and assign qualifiers
to profiles, and that kind of thing.

It would be a few hours work to make a KDE GUI that sat on top of
colord and did the following things:

1. CreateProfile for any icc profile in a well known location in $home
(colord doesn't have access to /home due to encryption and/or SELinux)
2. CreateDevice for any xrandr devices (colord can't access the X session)
3. Set the XOrg _ICC_PROFILE atoms on the x11 device and screen in
response to a query to colord
4. Watch colord for changes and update any GUI widgets
5. Make a widget to choose a profile for a device and to set a
qualifier for that profile.

colord stores both persistent devices and the mapping between devices
and profiles in a database, so it's quite legal to just call
device.AddProfile(p) in a control center type widget, which colord
will save in the database and then automatically apply if the device
*and* the profile ever show up again at the same time.

In fact, that's exactly what the 'icc' branch of gnome-color-manager
is working towards.

As always with a new project, please use git master if you're
evaluating it, we have already:

 43 files changed, 4008 insertions(+), 274 deletions(-)

Since the last release :-)

Richard.


More information about the openicc mailing list