[Openicc] Helping with colord

[Kai-Uwe Behrmann]

Am 08.03.2011 02:01, schrieb 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.

lcms has many sides where it extents traditional CMM functionality. But
agreed the term is fuzzily used.

> "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.

Interesting definition.

>> 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.

I would not start a new term without first defining the existing ones.
But you did already above.

>> 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.

Amen.

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

kind regards
Kai-Uwe