Color Management in KDE

[Daniel Nicoletti]

2013/2/2 Kai-Uwe Behrmann <ku.b at gmx.de>:
>> * Is integrated into CUPS only due to Red Hat pressure, it seems highly
>> unlikely Apple will add Oyranos support
>
> Michael Sweet from CUPS said, he would not oppose linking to Oyranos, but
> expects more code to make it reality. We from the Oyranos project said, that
> a session daemon, like colord, inside CUPS server makes technical,
> administrative and security wise not much sense.

There's no such thing as a colord daemon inside CUPS, there's only
a runtime dependency to get the printer profile and code inside CUPS
that applies that to the print job.

>> * Plans already underway for a shared config, so seems pointless to
>> duplicate
>> the DBus service as well
>> * Seems unlikely Qt5 will choose to support both, colord seems more likely
>> * Keeps our dependencies clean and simple, as well as our code
>
> You focus on DBus. Maybe a DBus API helps on one single platform. But it is
> a IPC mechanism and no abstraction layer.

You have DBus on pretty much any *NIX plataform (tho some features aren't
available in all of them) and afaik there's some effort to bring it to Windows.
Having an abstraction layer is not the job of who provides the ICC <-> device
association, it would be the job of some Qt engineering wiling to provide a
QColorCorrection class to do the tranformation on some surface, at this point
it would need to know how to talk to OSX, Windows and Linux CMFs just to get
which profile to use.
So yes, we focus on DBus to make it easy for GTK and Qt applications to get
what does matter, and avoid linking with code that might crash apps, it does
make total sense...

> On the other side Qt would have to write, test and maintain many platform
> code. The Qt project needs certainly a expert for that work.
> ICC colour managemenet is a complex topic on the scale of i18n or printing.
> Projects which successfully implemented ICC support engaged with a
> specialist. Either the person involved in that work became a specialist
> after lots of learning with the needed enthusiasm or the project hired a
> colour scientist. In any way it took the projects many years to figure
> concepts out including testing and fixing sometimes essential bugs.

Sure they need an specialist, after all they provide a commercial solution,
and abstracting is what Qt devs do better, look at the window system,
print system, compilers and lot more that they have to abstract...

>> So what does that mean for Oyranos?
>> * Already planned to share a common config, we will still support Oyranos
>> until implemented
>> * Saves Oyranos having to build and support own DBus service and keep in
>> sync
>> with colord's service
>
> I am not so sure that will help. colord follows a minimalistic approach as
> is typical to GNOME. At the moment Oyranos supports quite more features.
>
> In regards to colord we gave up our requests to see certain features added
> and maintained. We wanted some policies considerd for ICC shared profiles,
> which is a essential part for Oyranos. But these whishes where completely
> ignored. We try to work around things and hope to cooperate better based on
> specs.
Who wrote the specs? You did right? So what about providing good use cases
and not complex features that will just make the code more likely to have bugs
and less likely to get used by real people. We are always open to new features
when they do provide a good use case.

>> colord
>> ------
>>
>> * Linux only, CMF only
>> * Not a CMM, leaves that to toolkit, app or window manager
>> * libcolord gobject C library, LGPL 2.1
>> * Config stored in DConf
>> * DBus service & api for all options
>> * Command line tool for all options
>> * Intergrated into GTK, CUPS, SANE, etc.
>
>
> SANE-backends-1.0 (e.g. libsane.so) has no dependency to DBus or colord.
> Each colord client, which likes to support SANE has to implement that by its
> own. colord has no device specific code inside. ldd shows that easily on
> Linux.
colord doesn't need to have device specific code, since it only provides a mean
to match device <-> ICC, OTOH it does have device specific code for
the calibration
devices.

>> Oyranos
>> -------
>>
>> * CMF and CMM abstraction API
>> * Linux and BSD support using own CMF implementation
>> * OS X native ColorSync CMF support
>> * Plans for Windows CMF support
>> * CMM api only supports lcms/lcms2, plans to re-write to support more
>> CMM's
>> * C library, BSD license
>> * No DBus service
>> * Command line tools for certain options
>> * No integration into CUPS, GTK, SANE, etc.
>> * Not fully stable api yet
>> * Must be hard build time dependency
>
> Every CLI tool can be called at runtime especially easy on Posix systems.
> That is not much different than DBus. So it would in theory be possible to
> use Argyll/Oyranos or colord in exchange without hard linking. I guess the
> amount of code might be similar like supporting all those different DBus
> APIs + support code.
Using command line tools is actually extremely hard/boring if you need to keep
parsing it's output, QtDBus brings you all the convenience of SIGNALS and SLOTS
and is async as well.

> Let me add an advantage. Argyll and Oyranos have the needed device dependent
> code already inside. No need to fiddle with EDID, X11, CUPS and other API's.
Since the work is so small I don't really see such advantage...

>> In some ways Oyranos could be seen as an alternative to Qt in providing a
>> common abstraction api across the major platforms, except it is in C, not
>> yet
>> on Windows, and requires explicit CMM code rather than having it implicit
>> in
>> the Qt graphics classes.
>
> The last half sentence makes no sense to me. First of all. lcms is the most
> highly valued CMM on the planet right after the AdobeCMM. It's portability
> is simply amazing.
> CMM code is dlopen'd in Oyranos on demand. E.g. KolorManager will never link
> against or call lcms.
>
> On the opposite, a ldd to libcolord.so shows a hard dependency to
> liblcms2.so .
>
> Qt graphics classes are dependent to any CMM in what way? Are Qt apps free
> to choose a CMM if Qt graphics classes have already choosen one?
There is no color correction in Qt yet, dlopening a library is
actually a much worse
practice than linking against it, if lcms change their API you won't notice
at compile time and might give nice crashes with odd backtraces.

> I did not even hear about that service. Even though I am one of two persons,
> who had worked on specs for a shared CMS DB on Linux. The other person is
> Graeme Gill. His implementation is based on JSON files, which I find sound.
You should really rethink about JSON, it should only be used on the web...

> Let me outline point 4) and what I expect that to become:
> colord is mostly a small API for DB queries. The DB itself is otherwise
> hidden. The outlined project will need many own code to implement the basic
> device and driver configuration detection. Or it can choose to ignore
> aspects leading to a poor implementation. As soon as one has written all the
> needed code for KDE or Qt it needs to be continued for each other supported
> platform. Thats the logic. In the end it means parts of Oyranos or GCM get
> rewritten in a Qt specific style. All remaining Linux DE's have to rewrite
> everything by themself too. The actual Gnome CM (colord) way makes a massive
> repeat of code necessary. IMO that is a waste of programmers energy. Because
> KDE/Qt will for sure not provide a shared API suitable for any Gtk/EFL or
> other DE project out there.
I'm sorry but I really don't understand why do you keep saying about device and
drivers?
If you are talking about X then all you need to do is talk to XRandR which has
no sense to be abstracted in a library or put on some backend thing since on
Windows and OSX they will handly that.
So if KDE will write some color correction abstraction this would only
to allow apps like Krita to run on OSX/Windows/Linux without lot's of ifdefs
but after a talk to Richard Hughes he explained that they are too different to
abstract, and as with him I care most/only about Linux.

>> Let me be clear though, if an app wishes to use Oyranos directly as a hard
>> requirement because of some better functionality or less code then they
>> are
>> free to do so, but it does come at a cost that they need to be aware of, a
>> cost which I don't think belongs in kdelibs or Workspace.
>
> Hmm, reads like a plan to abstract from the Oyranos abstraction API. Maybe a
> graphics scheme could help in making that idea better understandable?

IMO if you could turn your Oyranos libs into a simple library and make
it into kdelibs
which didn't had hard deps with Oyranos or colord (only linked abaings
Qt/KDE and
lcms2), would be what Krita & friends would need...

Best,

--
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com