[Openicc] Helping with colord

[Graeme Gill]

Richard Hughes wrote:
> I don't see ArgyllCMS as a CMS. It's an excellent tool we can use to
> generate profiles, but it's not a component that we can, for example,
> say "give me all the profiles installed on the system". But that comes
> down to how you define a CMS. The ultimate example is lcms, which is
> an excellent library for converting pixels and reading data from ICC
> profiles, but again doesn't satisfy my definition of a CMS.

The terms are somewhat wooly. Traditionally, the term is "CMM"
(Color Management Module) is often used, and both lcms and Argyll
have functionality that qualifies for this (the ability to load &
link profiles, and transform image data). The ability to store an
association between devices and profiles is typically more of an
operating system function (System CMM ?), so you're right that lcms
doesn't qualify in this regard, whereas Argyll partially qualifies
due to support for display profile association.

"CMS" though, is a very general term that could be applied to any system
that manages any aspect of color. By many popular definitions, it is
any system that allows profiling of devices, so in this regard Mac ColorSync
and MSWin's ICM don't qualify, whereas Argyll does.

> Maybe it's me that's wrong in my definition. I should perhaps start
> calling colord a "Color Management Framework" as CMS as a term seems
> so horribly overloaded.

Yep.

> In colord, DBus is used as the transport. In Ghostscript we're
> registering profiles from the PPD with colord. GCM is getting the
> default monitor profile from colord and setting the _ICC_PROFILE
> atoms. The fact that I'm using DBus rather than a socket is just a
> trivial implementation detail.

I think that we could all get on the same page if there was an agreement
to work at a low enough level, hence my suggestion of a file format
with locking protocol to store the profile association information.
I can well understand that this seems inelegant, and inconsistent with
various existing desktop systems approaches, and re-inventing the wheel etc.,
but that may be the best technical and political compromise.

It would have the following benefits:

  * Works on almost any POSIX like system, and can be built into
    applications that want to be able to work on a bare system, yet they
    will still work cooperatively when systems provide the infrastructure.

  * Could be interfaced to Elektra, so that Oyranos can easily use it.

  * colord could provide a GNOME world interface including DBus, based on it.

(Figuring out what's stored in the config. is a whole other discussion
  of course.)

Graeme Gill.