Can someone point me to a description of what the experimental "color correction" feature of KWin actually does? There appears to be some interference with digiKam and Firefox' built-in color management for displays.
Can someone point me to a description of what the experimental “color correction” feature of KWin actually does?
Can someone point me to a description of what the experimental "color correction" feature of KWin actually does?
It's supposed to only colour correct those windows that are not already colour managed, so if it is messing with Digikam and Firefox that suggests a bug.
John Layt then the question is, how would it know that an application is already color managed? It can't, because the "chrome" never is, except certain areas. For example, in digikam only the photos are color managed, the application UI itself is not. It's therefore correct to assume sRGB for the UI elements (unless there are icons tagged with a color profile), but photos need not be converted again.
The more you think about it the more complex it gets: Imagine your working colorspace is ProPhoto for maximum gamut. To display the photos correctly with Kwin color correction, you'll have to tell digikam that the display is sRGB, so that Kwin's assumption on the source color space is correct. That means digikam will reduce the color space to sRGB for display. Then Kwin will transform it from there to the actual display color space. That's a lot of multiplications. I'm not sure it will be without visual degradation. Color output precision will definitely suffer.
The more I think about it the less I believe that putting the transformation into KWin is the right idea.
Exactly, it is very complex, and I don't understand the details of it myself. I do know apps are supposed to set an X Atom to say what windows are colour managed so perhaps that's the issue. Or it could be that we have both Oyranos and colord being used and not agreeing on the correction to use. Or just a bug 🙂 The proper solution is for all the widget toolkits to become colour managed, i.e. it's all done implicitly in Qt and Gtk graphics classes, and kwin only manages those apps done in non-managed toolkits, but that goal for Qt is a way off.
Unless the apps are really color managed, i.e. know that they are drawing in a specific color space and do the output transformation themselves, setting an application wide X Atom will only result in "different shades of gray". If digikam sets this Atom and Gwenview doesn't, the UI of digikam will appear in different colors than Gwenviews', and only the displayed photos will appear identical. That is certainly not what we want.
The alternative is to give Kwin an area list or mask to tell which parts of an application are to be submitted to color space conversion. But that also needs a lot of toolkit support to maintain that information while UI elements resize, move around, scroll, etc...
Yes, which is why it's important to get it into the toolkit, have all the chrome managed from a single common desktop config and the app controls how the embedded graphics context is managed by the toolkit, either using the desktop wide config or it's own if it knows better. Then all KWin needs to worry about is the non-managed toolkits. Unfortunately the current state is a mess and will continue to be until Digia makes the effort required to fix Qt, and the separate colord and Oyranos config situation gets sorted.
Or I could be completely wrong, like I said I'm no expert 🙂
Oh, and here's some links http://skeletdev.wordpress.com/2012/08/20/gsoc-color-correction-in-kwin-final-report/ and http://community.kde.org/KWin/GSoC/Color_Correction