Back to the main page
No.
Version numbers are of the form ${major}.${minor}.${micro}.
| Git Branch | Version Numbers | Maintained Status |
|---|---|---|
colord-0-1 | 0.1.* | obsolete |
colord-1-0 | 1.0.* | stable, getting backported fixes |
master | 1.1.* | unstable, getting fixes and new features |
Branches with the status stable are suitable for distributions like SLED
and RHEL and are 100% ABI and API stable. Translatable source strings will not be
added or modified and dependancy versions will not be updated.
Tarball releases from this branch should be considered safe to push to users as
normal updates.
Branches with the status unstable are suitable for distributions like Fedora
or jhbuild and are potentially ABI and API unstable and will contain new
features, refactoring or new translatable strings where required.
Tarball releases from this branch should be QA'd before pushing to users
as test updates.
Branches with the status obsolete do not get backported fixes,
although may get security fixes backported if it is practical to do so.
Every 6 months (roughly aligned to the GNOME release schedule) we will branch a new minor version from master, so the new stable version is 1.(n+1).0 and the new unstable version is 1.(n+2).0. This means that even minor versions are stable, odd are unstable.
At start-up either gnome-settings-daemon or colord-kde has to create profiles and devices and otherwise act as the helper agent for colord in the user session. The session client has to do the following 6 things:
CreateDevice for each connected XRandR screen and
watch for changes to the screen.
CreateProfile for each profile found in the home
directory.::profile-added event check if the
EDID_md5 metadata matches any XRandR devices.
If it does, then it needs to call Device.AddProfile()
::device-added event check if the device
modified property is beyond a set threshold.
If it is, show a notification that the user should calibrate the device.
::device-added event from a XRandR device,
get the default profile and push the gamma ramp to the X output.
No. XRandR 1.3 is required to do per-output gamma correction.
You can use the CdTransform object in libcolord for simple RGB->RGB transforms. You need to use a pixel conversion library, for instance lcms2 for anything more complicated.
If you have a registry that more than one program is changing, you need locking. Locking with plain files is neither fun nor reliable. From a raw performance point of view, it's two orders of magnitude faster to mmap a single 20k sqlite .db file than it is to read 200 small XML files from the file system.
The session needs to query things like give me all the profiles for device $foo and find all the devices that use profile $bar which is why we should be using a database, rather than searching discrete files on the file system every time the session asks for data.
If we're exchanging files between users, then single files do start to make sense. I don't personally see a use case where I want to exchange low level device->profile settings data with somebody else. A chain of settings from document to printer would be a very useful thing, but this is what you generate for a process and ship, rather than copy from the file system unchanged.
Having power users tweaking the mapping is something that does
not make good design.
These people can use the colormgr command line client to
add and remove mappings, and to append qualifiers to certain profiles in
a safe abstracted way.
The binary driver from NVIDIA only supports XRandR 1.2, which means that it does not support per-monitor gamma tables. This means we can only send gamma correction tables to the screen, which means multiple monitor would not be supported.
As the driver has no source code, we can't fix this and have to wait for NVIDIA to release a fixed version of their driver. Nowadays the open source nouveau driver provides a much better experience for NVIDIA hardware, and gnome-color-manager of course works flawlessly with all of the open source drivers.
A CMM (Color Management Module) is the software component that takes the pixels in an image and converts them from one colorspace to another. There are several CMM engines in existence, both free and proprietary. Free CMM engines include ArgyllCMS and lcms2, of which the latter is used heavily by colord and both are used by gnome-color-manager.
A CMF (Color Management Framework) is a software component that allows applications to register devices and profiles, and also allows applications to query what profiles to use for a device. A CMF is a higher logical layer component to a CMM engine -- in this way, colord aims to be primarily a CMF, and is not a full featured CMM.
It is the authors opinion that the abbreviation CMS is a heavily overloaded term (in that ArgyllCMS and L[ittle]CMS include them in their name), but do not actually provide a system framework for other applications to use. In casual usage, both LCMS and colord exhibit some parts of a complete CMS, and in this way CMS is often used as a general term for both a CMM and a CMF.
A native sensor is a calibration device such as a colorimeter or photospectrometer that colord knows how to interface with.
Many sensor makes and models are recognised, and are available to be used by programs such as ArgyllCMS. The following sensors have native drivers and do not need to spawn ArgyllCMS to take readings:
A native driver allows colord to lock the device, read a sample from the sensors (or from the ambient light sensor) and unlock the device. A native device allows client programs to get samples from the device trivially using either raw D-Bus or libcolord without relying on external programs.
A qualifier is a single string with three sub-strings joined with dots.
For example, RGB.Glossy.300dpi would be the qualifier on
a profile for a RGB device, printing on glossy paper and at 300 dots-per-inch.
Qualifiers are assigned to a profile either by CUPS itself or by the user
and this allows CUPS to choose the correct profile for a given print job.
The sub-strings are tried in preference order, so that for a print job
of type RGB.Glossy.300dpi the following fallbacks would be
used:
RGB.Glossy.300dpiRGB.Glossy.*RGB.*.300dpiRGB.*.**The fallback scheme allows one profile to potentially match lots of different print conditions, as very few users will have more than a couple of different printer profiles.
The tri-dotted notation was chosen in preference to JSON or XML as it
is
already being used by CUPS in the cupsICCProfile PPD
Extensions format.
It's actually really easy.
Simple Scan already knows the SANE_Device object of the
scanner that it wants to use.
From the SANE_Device object we can easily get the
device_id for the color managed device in colord.
To do this, refer to the
device and profile specification for scanner devices.
This specifies the device_id for a sane device is made up from
"sane_" + sane_device->model.
We can now query colord using libcolord for the device that matches this ID:
CdClient *client = NULL;
CdDevice *device = NULL;
CdProfile *profile = NULL;
GError *error = NULL;
/* create a connection to colord */
client = cd_client_new ();
/* find the device for a specific ID */
device = cd_client_find_device_sync (client, device_id, NULL, &error);
if (device == NULL) {
g_warning ("failed to find a device in colord: %s,
error->message);
g_error_free (error);
goto out;
}
/* get the default profile for this device */
profile = cd_device_get_default_profile (device);
if (profile == NULL)
goto out;
/* TODO: use lcms to convert the scanned image */
g_message ("need to use: %s", cd_profile_get_filename (profile));
out:
if (profile != NULL)
g_object_unref (profile);
if (device != NULL)
g_object_unref (device);
g_object_unref (client);
If you're not happy gaining an additional dependency of libcolord, then it's also pretty easy to use raw D-Bus calls to do the same thing. See the examples folder for some code samples.
Like this:
for device in self.devices:
o = CreateDevice(device.name)
for profile in device.profiles:
p = AddProfile(profile.id)
if profile.icc_filename:
p.SetFilename(profile.icc_filename)
p.SetQualifier(profile.qualifier)
o.AddProfile(p)
Like this:
d = FindDeviceById(device.name)
if d:
p = d.GetProfileForQualifier(qualifier)
if p:
p.Use()
See the colord Transifex pages for how to contribute to localisation.
colord is not sponsored by anyone, although Red Hat gives me the time to work on random open source projects. Thanks!
On the surface, Oyranos and colord look like similar projects. I'm not going to be able to write an unbiased comparison against colord and Oyranos (as the author of the former) but I've supplied the table below which hopefully helps.
| Oyranos | colord | |
|---|---|---|
| Portability | Windows, Linux, OSX | Linux, FreeBSD[1] |
| Desktop support | FLTK (native) and KDE | GNOME, KDE and XFCE, LXDE, MATE |
| Client access | C | C, DBus (native), all others via GObject Introspection |
| Client library | Synchronous, and not MT-safe | Synchronous, asynchronous and MT safe |
| Lines of code | 151k | 46k |
| Memory allocation | custom | GLib |
| Object system | custom | GObject |
| Build system | custom | automake |
| Settings store | elektra [2] | sqlite |
| Session presentation | photographer, prepress and designer | None [3] |
| Full screen color management | Compiz, using X atoms as IPC | Wayland with subsurfaces used as opt-out areas (WIP) |
| Project age | 9 years | 3 years |
| Required by |
Notes:
Since version 0.1.12 (released August 2011) colord runs as the colord user, not root — if you're still running this or an older version please file a bug with your distribution to get it to upgrade the package to something more modern!
The original reason for running as the root user was to check the PolicyKit authorisation request, but PolicyKit 0.104 (released October 2011) added functionality to allow non-root daemons to do this as well.
Applications can query colord directly, or can use the per-session
_ICC_PROFILE X atom.
| Software | colord support | _ICC_PROFILE support | Notes |
|---|---|---|---|
| GTK+ | Yes | No | Only the print dialog |
| Simple Scan | Yes | No | |
| GIMP | No | Yes | Need to enable it before use |
| Firefox | No | Yes | Need to enable it before use |
| Eye of GNOME | No | Yes | |
| Darktable | Yes | Yes | |
| Krita | No | Yes | |
| Calligra | No | Yes | |
| Digikam | No | Yes | Need to enable it before use |
| UFRaw | No | Yes | |
| Inkscape | No | Yes | |
| Entangle | No | Yes |
Anyone interested in colord development is invited to join the
channel #gnome-color-manager on irc.gnome.org.
We are a friendly bunch, and can answer questions on D-Bus interfaces,
general lcms questions or anything else colord related.
Back to the main page