Re: [Openicc] colord 0.1.0 released!
- From: Richard Hughes <hughsient gmail com>
- To: Robert Krawitz <rlk alum mit edu>
- Cc: twaugh redhat com, openicc lists freedesktop org, gnome-color-manager-list gnome org
- Subject: Re: [Openicc] colord 0.1.0 released!
- Date: Mon, 17 Jan 2011 09:38:49 +0000
On 17 January 2011 02:48, Robert Krawitz <rlk 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 :-)
] [Thread Prev