Post navigation

KDE End to End Colour Management

The last blog posts about KDE and colour management might have been irritating about what actual happens on colour managed desktops. Here come some clarifications and thoughts from the Oyranos CMS maintainer. The project name starts with Oy (Oyranos like sky), hence my nick oy on IRC

Colour Management Systems (CMS) are a precondition to do colour correction of input and output devices. But this is not sufficient for having a colour corrected desktop. The claim was made, that Gnome is the first colour managed desktop on Linux. But Gnomes window manger mutter has no means to use ICC profiles. The same is true for all other window managers with an exception of old Compiz. A CMS selects only the needed ICC profile and does the configuration in that field. But the background, applications like the dock and most others are not colour corrected by standard ICC profiles mechanisms in Linux. The only thing users can do since many years on Linux is to do monitor calibration setup per single channel. This helps for better grayscale, but not for compensating of colour gamuts. Calibration is only a first step, but not sufficient for ICC colour correction. So Gnome users have today no colour corrected desktop like all other Linux users.

What is needed to get to a End to End colour corrected desktop in KDE? A more general Overview can be found here.

KWin needs ICC support, in order to colour correct the KDE desktop in a reasonable time frame. That will help with the output side in a fast way by using the GPU during compositing while using few resources. If you feel it is time to do something, here is a Google Summer of Code CM project idea for KWin. With my experience from the CompICC project, I would be glad to help any such project.

An other project I would find really helpful is to provide colour correction to KDE’s primary image viewer gwenview. If people could help with a hackfest, that would be cool. We have such thing in mind and some ideas about, maybe you like to join us.

Qt/KDE needs to explore how to do own fast colour correction of a complete window to be prepared for the future. Here are two project ideas.

OpenICC did investigate to get print colour management right. There are currently two approaches who are promising. OpenICC has one project idea to introduce colour managed printing into Krita and one for user profile setup for colour managed print queues with KolorManager. These are two complementing, maintainable and robust paths for getting printing CM right.

Now some clarifications about Oyranos itself, as in the kde-planet where many wrong statements transported intermixed with half true claims.

The Elektra API and library is used for format independent configuration DB access.

Oyranos is planed to switch to a OpenICC JSON DB format to converge with ArgyllCMS and other interested CMS’es

Oyranos is a cross platform project

A DBus API would be welcome on top of the basic library but not in its core

Oyranos forces no one to use the CPU or prohibit to use the GPU

The CMS provides means to do optional multi monitor colour correction and other conversions.

CompICC uses Oyranos and does colour correction on the GPU

Oyranos developers belief in collaboration

Self containment in Oyranos results from adhering to and work on interoperable standards.

User configurations belong to users in Oyranos, so it needs no special root rights, which exposes security and privacy risks.

Oyranos provides optional policies for grouping single settings. That is a additional feature not a limitation.

Oyranos uses many advanced automatism’s to do it’s work successful

The CMS is designed to work with default settings.

Advanced manual configurations are supported and part of Oyranos’ user centrism.

Oyranos cares about quality and requires a careful selected and peer reviewed profile set that comes with no Fakes and no wrong colorimetry.

Licensing fits most open source and commercial projects with a newBSD style license.

Choice is a good thing for users. As a CMS author I have no problems, that an other CMS comes to KDE too on Linux. Many Linux CM standards I initiated or helped with allow for such interoperability, which is in the spirit of the ICC standard.

14 thoughts on “KDE End to End Colour Management”

I believe this post is “inspired” by colord and its KCM, so I’ll write my opinion about that. Imho, colord should be only a short-term solution because to have “not much” is better than to have “nothing”. While in the mid/long-term we should push Oyranos because it seems “better”.

Yes, it’s a shame we can’t have decent color management on Linux desktops. You read a lot of people counseling people to switch to Linux, well, hence why professionals of design and photography can’t if the want to spend their time working and not configuring all the programs they use to make sure all them manage the color correctly.
I wish all the best to this project, .

With littleCMS, ArgyllCMS and other projects decent colour management on Linux is possible.

Once applications support embedded ICC profiles in content, they should work pretty out of the box. For device profile configuration, a CMS is exactly what applications need, except they want to do the work on their own. As soon as conversions happen, these should be user controllable. The later needs quite some cooperation among different projects.

Hmm, the project, which Mr. Alexandre names, was not cited by me. My post addresses fictions about the Oyranos CMS.

To the second half sentence.
Calibration is in ICC terms the setup of a colour device to a good basic behaviour. 2D LUT’s, like present in the VCGT tag and as mentioned in my post above, belong clearly to that. It is in many cases a first step done before characterisation, which are encoded into ICC device profiles for easy exchange. ICC device profiles describe the current colorimetry of a device. For full screen ICC style colour correction exists only one full featured compositor. That is Compiz through the CompICC plug-in as described in the post above. I would be glad tho know any other compositor or detailed plans to bring full screen colour correction to the Linux desktop. The wayland CM scheme is the only other document I am aware of. And I discussed it with it’s author previous to it’s creation. Otherwise I have seen only non-binding letters of intent without any further details.

I even waited for the Gnome colour guys to reach consensus about that matter with them. But they did not work on this, there was no technical discussion and there was no progress except a fuzzy interview. My waiting for Gnome was a error, as KWin would now already be colour managed like Compiz. OpenICC has KWin now again in it’s GSoC list.

You know, it’s amazing. You are basically looking at the list of critics towards colord that was either met or unapplicable, and you are not seeing it. The last paragraph practically mentions it except not by the name and you still fail to see it. Well, you’ve chosen ignorance, this is your way.

Personally, I’ve had enough of this BS. I spent some time advocating Oyranos in the past, but I cannot support a project whose lead developer is so scared to not be able to deliver that he’s using any dirty tactics he can think of. Good luck.

What you interpret in your blindness in other sayings is not my problem or that of others.
There is a clear statement everyone, except you can see it. It says freedom is the freedom of choice!
That this looks to many better then “I gave up on working with Kai-Uwe a long time ago. Oyranos and colord
are competing frameworks that have *very* different design ideologies.” – http://lists.kde.org/?l=kde-core-devel&m=132991162010595&w=2

Its really funny, to talk a lot of such bullshit and then saying its the tactic of others to bring you to talk such shit!