Color Management in KDE

[Kai-Uwe Behrmann]

Am 02.02.2013 22:33, schrieb Daniel Nicoletti:
> 2013/2/2 Kai-Uwe Behrmann <ku.b at gmx.de>:

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

Oyranos is based in many aspects on community driven spec from OpenICC. 
I have the impression you did not read the OpenICC wiki pages, the specs 
or email list. That's probably a problem for a person, who wants to 
maintain a CM stack inside KDE. You completely depend on one API and the 
word of one person without good own reasoning. That's all you offer KDE.

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

Coding device specifics in each client makes detection of driver 
settings more error proune, as is it is a not simple and is a repeating 
and to be continued task.

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

In KolorManager we do it *with* SIGNAL + SLOT for asynchronous tasks. No 
problem.

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

The concept in colord is to use a device ID, which is a actificial name. 
That one might have nothing to do with actual colour behaviour and thus 
is eigther only particial useable for profile association or inflexible. 
What appears small work to you results from the omitting of real world 
use cases.

>>> 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 write what you imply. Your blindly jump to hostile assumptions 
about a project you appearently did not care to look much into.

The Oyranos CMM wrapper modules in question link against lcms, but the 
modules themself are dlopend like any normal plugin system does.

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

The whole chain of drivers, their colour related options, the colour 
device itself + involved media influence all the colour result. This 
chain has to be reproduceible, otherwise reproduction of colour is not 
managable. ICC profiles are merely a characterisation of a certain 
colour reproduction state. A CMS typical tries to get all required 
infomation to reproduce a colour behaviour and get most parameters to 
reduce unwanted disturbance. That's the reason why driver settings must 
be covered as well. In the case of X11 that might be switchable colour 
primaries, which are detectable over the EDID data. For most other 
device classes exist at least gamma and more driver parameters, which 
need to be taken into account for profile selection.

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

There exist at least two open source implementations, which exactly do 
this kind of abstraction. Applications use these and in parts own 
abstraction layers.

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

Funny.

regards
Kai-Uwe Behrmann
-- 
www.oyranos.org