Re: [GSoC] KWin colour management
Thank you for all this feedback!
Meanwhile I have been documenting myself and looking into relevant
code (and following this thread). I can't argue on the complex
technical issues and decisions.
2012/3/20 Martin Graesslin mgraess...@kde.org:
There is more into it: first of all KWin currently does not distinguish
between
screens during rendering. To properly have screen aware color correction the
complete compositor has to be made screen aware. The repaint loop has to be
split into multiple rendering passes - one for each screen. This is quite a
change in the way how KWin renders, but might be a useful change.
Okay, this would involve complicated changes, consequently it should
be like a separate sub-project. At the moment I don't know well enough
how KWin renders from my limited current understanding of the code,
but there will be enough time to discuss and see how this could be
done. It is good if this change is possible without massive intrusive
modifications throughout KWin.
As a second step all fragment shaders need to be adjusted to do the color
correction. This has to be done extremely efficient. This is a rather critical
code path especially for low-end hardware (think of old Intel GPUs). Given the
constraints of the GPUs a dynamic feature activation is not possible.
I have a rather crazy idea about how to achieve this for *all* of the
fragment shaders without modifying each one. It might be a silly idea,
but it's worth proposing it.
Every one of these fragment shaders respect the following structure:
1. declarations, functions, uniforms, whatever
2. void main() {
3. fragment shader functionality (whatever the shader does)
4. gl_FragColor = some_expression
5. } // closing bracket, end of shader
Now, colour correction would require this gl_FragColor result to be
different, to be altered. If I understand the shader assembly thing in
CompICC, it would be an alpha demultiply, a 3d texture lookup to
correct the color, and an alpha remultiply. Let's assume this code is
kept in a GLSL function, namely vec4 correctColor(vec4 c). This
function will require a sampler3D.
To make the above code do the color correction, we need to do the following:
* insert the sampler3D declaration and the function definition just
before main()
* alter gl_FragColor = some_expression -- gl_FragColor =
correctColor(some_expression)
These alterations are not *that* complicated, and they shouldn't
introduce any strange instabilities. Similar, but simpler alterations
are already made in GLShader::compile() at kwinglutils.cpp around line
295. Colour correction could be easily disabled at this point.
The tricky part is how to know what window / screen we're compiling
the shader for. This can be done with some little complications, maybe
an extra parameter, or some kind of member for GLShader, or some evil
static variable / member.
The advantage is that it avoids modifying all the fragment shaders
everywhere, but it brings these (i hope slight) complications to
GLShader. What do you think about this?
Oh, and what does dynamic feature activation mean? If it means what
I think it means, then it can be handled by the above idea.
What is in general important to know is that we have not had the best
experience with GSoC students doing work on the core of KWin. Given that I
proposed guidelines for future feature additions to KWin by non-core
developers [1].
Those are really strict guidelines, but I guess they are well based
given the past experiences, so I won't complain. There are a couple of
points that this possible project does not appear to respect, but
those are unclear and debatable when applied to this, in my view.
However, it looks to me as if no further significant features can be
added to KWin if you respect all those points by the letter.
Probably the colour correction code can be kept isolated in a couple
of separate files, without interfering much with the normal KWin
workings. This code would be responsible with getting the lookup
textures for the monitors (or screens) and the windows (possibly). It
may turn complicated and large, but at least it would be isolated.
Given recent discussions on this mailinglist about Oyranos and colord I am
very unsure whether I want any color management relevant code in KWin at the
moment. I will definitely not accept any code supporting only one of the two
systems and any additional build or run-time dependency to KWin will not be
accepted.
Alright, so this colord is a must, eventually. I should document
myself about colord too. But at least I could ask not to make it part
of the objectives for the summer.
In general there seems to be agreement that color management has to be done
inside the toolkit/application and not inside the compositor. A fully color
corrected compositor seems feasible to me, but one where some applications
need to start opting-out of being color corrected is nothing I want to see in
KWin as it adds significant complexity and
Re: [GSoC] KWin colour management
I forgot about the KWin ML :(
And I realized the complications for the strange idea regarding
GLShader are not even remotely necessary, bad thinking on my part.
Explanations below.
2012/3/22 Casian Andrei skelet...@gmail.com:
Thank you for all this feedback!
Meanwhile I have been documenting myself and looking into relevant
code (and following this thread). I can't argue on the complex
technical issues and decisions.
2012/3/20 Martin Graesslin mgraess...@kde.org:
There is more into it: first of all KWin currently does not distinguish
between
screens during rendering. To properly have screen aware color correction the
complete compositor has to be made screen aware. The repaint loop has to be
split into multiple rendering passes - one for each screen. This is quite a
change in the way how KWin renders, but might be a useful change.
Okay, this would involve complicated changes, consequently it should
be like a separate sub-project. At the moment I don't know well enough
how KWin renders from my limited current understanding of the code,
but there will be enough time to discuss and see how this could be
done. It is good if this change is possible without massive intrusive
modifications throughout KWin.
As a second step all fragment shaders need to be adjusted to do the color
correction. This has to be done extremely efficient. This is a rather
critical
code path especially for low-end hardware (think of old Intel GPUs). Given
the
constraints of the GPUs a dynamic feature activation is not possible.
I have a rather crazy idea about how to achieve this for *all* of the
fragment shaders without modifying each one. It might be a silly idea,
but it's worth proposing it.
Every one of these fragment shaders respect the following structure:
1. declarations, functions, uniforms, whatever
2. void main() {
3. fragment shader functionality (whatever the shader does)
4. gl_FragColor = some_expression
5. } // closing bracket, end of shader
Now, colour correction would require this gl_FragColor result to be
different, to be altered. If I understand the shader assembly thing in
CompICC, it would be an alpha demultiply, a 3d texture lookup to
correct the color, and an alpha remultiply. Let's assume this code is
kept in a GLSL function, namely vec4 correctColor(vec4 c). This
function will require a sampler3D.
To make the above code do the color correction, we need to do the following:
* insert the sampler3D declaration and the function definition just
before main()
* alter gl_FragColor = some_expression -- gl_FragColor =
correctColor(some_expression)
These alterations are not *that* complicated, and they shouldn't
introduce any strange instabilities. Similar, but simpler alterations
are already made in GLShader::compile() at kwinglutils.cpp around line
295. Colour correction could be easily disabled at this point.
The tricky part is how to know what window / screen we're compiling
the shader for. This can be done with some little complications, maybe
an extra parameter, or some kind of member for GLShader, or some evil
static variable / member.
We don't need to know that! Distinguishing between windows and screen
can be done just by binding different lookup textures, no need for
extra parameters or useless complications. The altered shader just
tries to do colour correction. If it gets a default sRGB-sRGB lookup
texture, then no colour correction. And I think there are many ways to
disable it altogether - something like that kwin_shader_debug
definition.
The advantage is that it avoids modifying all the fragment shaders
everywhere, but it brings these (i hope slight) complications to
GLShader. What do you think about this?
So, minus the complications.
Oh, and what does dynamic feature activation mean? If it means what
I think it means, then it can be handled by the above idea.
What is in general important to know is that we have not had the best
experience with GSoC students doing work on the core of KWin. Given that I
proposed guidelines for future feature additions to KWin by non-core
developers [1].
Those are really strict guidelines, but I guess they are well based
given the past experiences, so I won't complain. There are a couple of
points that this possible project does not appear to respect, but
those are unclear and debatable when applied to this, in my view.
However, it looks to me as if no further significant features can be
added to KWin if you respect all those points by the letter.
Probably the colour correction code can be kept isolated in a couple
of separate files, without interfering much with the normal KWin
workings. This code would be responsible with getting the lookup
textures for the monitors (or screens) and the windows (possibly). It
may turn complicated and large, but at least it would be isolated.
Given recent discussions on this mailinglist about Oyranos and colord I am
very unsure whether I want any
Re: Re: Re: [GSoC] KWin colour management
Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: Where would be a competing system on Linux? Well, I certainly did not read all of that colord ./. oyranos flamewar on k-c-d where supporters of either basically tagged the other like incapable and/or irrelevant s..tufff, but I as certain did not dream about it. So while this might just have been kindergarten s...tuff about xyz uses mono and we hate mono, I was under the impression that those were conflicting approaches to CM. If it indeed only is about implementation details on the very same protocol, thus whether colord or oyranos is in use does absolutely not make any difference regarding the compositor, I wish apologize and withdraw that particular concern. screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Ok, so let me please complete my former question by its implications: Does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol [...], it will be reduced to sRGB while the application and the screen actually could do WG ... ... unless I suspend compositing or switch to another window manager what, because I'm just a user and don't know what a window manager is, likely means to switch to another DE, because it just works on - let's say - Trinity? We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 Many thanks. But that seams clearly away from per-region opt-out but into per-window opt-out, doesn't cover different screens anyway and require toolkits to colour correct the whole window what -if did not terribly misunderstood- also means that if Qt Gtk+ support such, but TCL/TK does not (just examples here), the result would be that w/ or w/o a color correcting compositor, my Qt Gtk apps just work fine whereas my very important professional offset print preview POPP (tm) tool written in TCL/TK only works WITHOUT such compositor (because the canvas is corrected internally and the buttons are all gray anyway) and fails with one. Is that correct? Cheers, Thomas
Re: Re: Re: [GSoC] KWin colour management
Am 23.03.12, 17:10 +0100 schrieb Thomas Lübking: Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: Where would be a competing system on Linux? Well, I certainly did not read all of that colord ./. oyranos flamewar on k-c-d where supporters of either basically tagged the other like incapable and/or irrelevant s..tufff, but I as certain did not dream about it. So while this might just have been kindergarten s...tuff about xyz uses mono and we hate mono, I was under the impression that those were conflicting approaches to CM. That was likely related to Linux CM DB APIs, but not particular to compositor CM. If it indeed only is about implementation details on the very same protocol, Yes, we have seen no other descriptions for a compositor CM protocol. thus whether colord or oyranos is in use does absolutely not make any difference regarding the compositor, I wish apologize and withdraw that particular concern. screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Ok, so let me please complete my former question by its implications: Does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol [...], it will be reduced to sRGB while the application and the screen actually could do WG ... ... unless I suspend compositing or switch to another window manager what, because I'm just a user and don't know what a window manager is, likely means to switch to another DE, because it just works on - let's say - Trinity? sRGB displaying is for many people the it just works. They likely will find sRGB be more relaxing, if they have a wide gamut display. Look at the email threads, where people search for the sRGB emulation mode for these kind of monitors. We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 Many thanks. But that seams clearly away from per-region opt-out but into per-window correct opt-out, doesn't cover different screens anyway and require toolkits to For different screens can be colour corrected through X Color Management, because the output device spaces are known. toolkit means client side. A client can as well be a application. colour correct the whole window what -if did not terribly misunderstood- It is about specifying a per window opt-out or per window source colour space. A compositor can still apply different per monitor colour conversions. also means that if Qt Gtk+ support such, but TCL/TK does not (just examples here), the result would be that w/ or w/o a color correcting compositor, my Qt Gtk apps just work fine whereas my very important professional offset print preview POPP (tm) tool written in TCL/TK only works WITHOUT such compositor (because the canvas is corrected internally and the buttons are all gray anyway) and fails with one. Your POPP (tm) tool written in TCL/TK will hopefull adhere to the ICC Profiles in X spec[1]. Otherwise it's behaviour is undefined. Such bug is present in Gimp, when the Use system profile check box is initially not selected. Gimp behaves correctly after enabling this option. kind regards -- Kai-Uwe Behrmann www.oyranos.org [1] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec
Re: Re: [GSoC] KWin colour management
Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin: I think you do not know how KWin's rendering works. In a simplistic way: a window is rendered to the screen through a shader. At runtime KWin decides which shader to be used. As by that there is always only one active shader, so to have color correction it has to be added to all shaders which render windows/textures/colors. Thanks for the description. This is different to any experience you might have from Compiz 0.8. There the screen was not rendered with shaders but plugins could use shaders. Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) As we discuss a equivalent of colour management in KWin, we talk about default colour management of all displayed Qt widgets. That is a high goal and likely coming with some API changes. Such changes need quite some preparation. What signs are visible that with the first release of Qt 5 will have full CM? Even if people would put CM now high on the Qt develpers or similar agendas, CM will likely not get included soon to be ready for the first Qt 5 release. Then logically the next feature window is Qt 6. On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. The X Color Management spec allows for opt-out inside compositors. I think to demonstrated you that on osC. and I think I explained to you why I don't think that's a good idea for KWin :-) kind regards Kai-Uwe
Re: [GSoC] KWin colour management
Am 21.03.12, 22:25 +0100 schrieb Thomas Zander: Color management in Qt is a bit of a weird statement; first of all, support is already possible as Krita proves. Second, I doubt that 94% of the widgets Krita does colour management inside Krita. IMO that does not belong to a discussion about Qt itself. actually need color correction of the type that kwin could provide. Who cares that their text edits and their buttons are color correct? Many people care about that and even more are positively affected. Its only for canvas-like widgets that this is relevant, and apps have that option already by linking to LCMS. It is relevant to the whole desktop experience. What people like to see are consistent colours on displays and then on prints. And they want to show the same colours to their friends remotely. At the moment KDE looks on each monitor different. No one can predict on what colours come over the internet, being it web sites, email clients or application toolbars. That's not so good. So, KWin support would just be a shortcut. A one-stop solution to make all apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its a shortcut. So please keep treating it as such. Yes. There needs work on many layers. All have to play their role. And I see default colour management in KWin as a big step in a good direction. When people talk about the toolkit adding support its more about convenience APIs. Think a QPainter method to set a color transform to do correction on following draws. Such a API is specialy tailored to a certain audience. Photographers come to mind. And I am all for it, but they are only part of the KDE user base. When people want support in the toolkit, they want the color selector widget, the print preview widget etc, that come with Qt to natively use the monitor profile. Last, they want the printing to take color management into account. Good example. The print of a screenshot should look like on screen. So the first thing is to make screens look consistent. Then printing has a chance to match that. All of those are possible and likely even welcomed in Qt. The only thing is that someone has to actually do it. So saying that it won't happen in Qt6 is a self-fulfilling wish, and I feel its not very fair to plant that doubt in peoples minds. Agreed with you. And luckily no one says it can not happen for Qt 6. What would KWin people suggest how and where to place this feature near KWin? Well the question is whether such a feature is needed at all. I would say: * either correct the whole screen * or let the windows handle it Now it becomes quite simple: there's an app doing color correction itself. In that case we can safely assume that the user wants the app to take care - compositor does no longer color correct the screen. There is no application taking care of it: compositor renders the whole screen. That could be a start. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 07:34 +0100 schrieb Martin Gräßlin: On Thursday 22 March 2012 07:02:27 Kai-Uwe Behrmann wrote: Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin: Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) As we discuss a equivalent of colour management in KWin, we talk about default colour management of all displayed Qt widgets. That is a high goal and likely coming with some API changes. Such changes need quite some preparation. What signs are visible that with the first release of Qt 5 will have full CM? Even if people would put CM now high on the Qt develpers or similar agendas, CM will likely not get included soon to be ready for the first Qt 5 release. Then logically the next feature window is Qt 6. Sorry but I don't follow that logic. Just because it won't make it into 5.0 (which is impossible) does not mean that it won't enter any 5.x release. And that's what I asked for: is there any reference stating that it won't be possible to add CM to Qt in the lifetime of Qt 5? Here my thoughts, why I think CM in Qt is not easily introduced during a minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.] Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. There is currently no API to know that. They will play freestyle as before and colour correct to monitor space without knowing how to tell anything to Qt. These old style apps will colour correct to monitor and Qt will colour correct from sRGB to monitor as Qt does not better know. That is called double colour correction and would be a real design bug. The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. An other way is verbally declaring sRGB as the default colour space in Qt, which would be a major API change as well and only reasonable possible during major version change. Both is not easy before Qt 5. After the fist Qt 5 release a new drawing API could theoretically be introduced in parallel to the old one. But old Qt apps would then look inconsistent compared to ones using the new API. Not sure if that transition path would be a good option regarding code complexity. IMO best would be to wait for Qt 6 and then switch completely. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: [GSoC] KWin colour management
2012/3/22 Kai-Uwe Behrmann k...@gmx.de: Here my thoughts, why I think CM in Qt is not easily introduced during a minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.] Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. There is currently no API to know that. They will play freestyle as before and colour correct to monitor space without knowing how to tell anything to Qt. These old style apps will colour correct to monitor and Qt will colour correct from sRGB to monitor as Qt does not better know. That is called double colour correction and would be a real design bug. The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. An other way is verbally declaring sRGB as the default colour space in Qt, which would be a major API change as well and only reasonable possible during major version change. Both is not easy before Qt 5. After the fist Qt 5 release a new drawing API could theoretically be introduced in parallel to the old one. But old Qt apps would then look inconsistent compared to ones using the new API. Not sure if that transition path would be a good option regarding code complexity. IMO best would be to wait for Qt 6 and then switch completely. I'm sorry but you point is wrong here. Even if the real problem was just API changing and old applications getting unaware of that this is the easiest thing to fix. When people draw API they have this in mind and we don't need a whole new Qt just to introduce a new feature, easy solution: QApplication::setColorCorrected(true); Done! All old apps won't be color corrected since they don't set that and all new ones will be able to have this. And I had only to think about it in 2 minutes, surely Qt devs will have a better solution. I'm not saying it's easy to add Color Correction to Qt, but API additions is no excuse.
Re: [GSoC] KWin colour management
On 2012-03-22, Daniel Nicoletti dantt...@gmail.com wrote: people draw API they have this in mind and we don't need a whole new Qt just to introduce a new feature, easy solution: QApplication::setColorCorrected(true); That's crap API thoug.h QApplication::setBehaveSane(true); QApplication::setPleaseDontCrash(true); QApplication::pleaseFixMyBrokenApplication(true); /Sune
Re: [GSoC] KWin colour management
2012/3/22 Sune Vuorela nos...@vuorela.dk: On 2012-03-22, Daniel Nicoletti dantt...@gmail.com wrote: people draw API they have this in mind and we don't need a whole new Qt just to introduce a new feature, easy solution: QApplication::setColorCorrected(true); That's crap API thoug.h QApplication::setBehaveSane(true); QApplication::setPleaseDontCrash(true); QApplication::pleaseFixMyBrokenApplication(true); Sure it is, I was just illustrating that it is possible to add that (even through crap API). I'm not an expert in Qt internals but surely they will think on something much clever.
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.2012, 08:55 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: Lets hypothetical assume some effort is initiated to bring CM to Qt and that happens during Qt 5 life time. The new design says by default all content is considered sRGB, which is by itself reasonable. However existing applications will initially not know about that changed convention. Errrmmm... how is that please different from opting out of the compositor? Except that latter does not only hit Qt applications but also *every* legacy stuff around? The conflict is solveable by making the new drawing API incompatible with the old one, e.g. requiring a colour space argument. Or by making user code color correction calls (QApplication::setColorSpec(int spec)?) invalidate/override library settings? Cheers, Thomas
Re: [GSoC] KWin colour management
Sorry I missed to answere you somehow. Am 21.03.12, 10:25 +0100 schrieb todd rme: On Wed, Mar 21, 2012 at 8:39 AM, Kai-Uwe Behrmann k...@gmx.de wrote: Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking: Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin mgraess...@kde.org: A fully color corrected compositor seems feasible to me I'm atm. not even sure about that. I might be utterly wrong, but my impression is that the xvidmode extension can correct screens (eg. xcalib loads icc profiles), so a screen wide color xvidmode gamma ramps are per channel curves. These are very limited compared to ICC based colour correction. Those gamma curves provide better gray balance and potentialy white point adjustment. But they do not describe colour primaries shifts or other more complex distortions. Gamma curves must be taken into account for ICC profiles. But detailed characterisation of device colorimetry happens usualy in ICC profiles. This may be an ignorant question, but can xvidmode be extended to offer more complex correction? That would end in a all desktop content is sRGB dituation. That would be fine as long as we know that wide gamut monitors are excluded, like on fixed hardware. Tablets could do that for their internal displays. But I am afraid a desktop, which cribbles all wide gamut monitors by default to sRGB, is suboptimal marketing. kind regards Kai-Uwe Behrmann -- www.oyranos.org
Re: Re: Re: Re: [GSoC] KWin colour management
On Thursday 22 March 2012 19:20:11 Kai-Uwe Behrmann wrote: Something like that is technical possible. But let me repeat, you get then a mixture of colour managed and non colour managed apps with the same toolkit, which is completely non understandable for users. First of all: users don't know anything about toolkits. If they use KDE Plasma Workspaces (and that's what this whole thread is about), they get three different toolkits looking exactly the same thanks to the effort of the Oxygen team. So how should users understand that their Firefox (GTK 2) is not color corrected, while the Qt app is? The issue - if there is any at all - will be quite simply resolved by the apps adjusting to it. It's a three line patch (ifdef, call, endif) for each app. If users really care about it, they will report bugs to the application (looks strange when running with Qt 5.x) or the more advanced will provide the patch directly (e.g. a distro could very easily do that). To me it is important to do it right. And if right means legacy is not supported, than it is like that. To me it looks like you are trying extreme workarounds just to make everybody happy and especially support legacy. Do yourself a favor: go for the easy part and forget about legacy :-) Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Re: Re: [GSoC] KWin colour management
Am 22.03.12, 22:49 +0100 schrieb Thomas Lübking: Am 22.03.2012, 19:20 Uhr, schrieb Kai-Uwe Behrmann k...@gmx.de: I was tould by the graphics community to keep the X Color Management spec backward compatible with the ICC Profile in X spec, so we did. Thus old style applications see a sRGB profile through the ICC Profile in X spec, and they continue to work by converting to sRGB. Sorry again, but does that actually mean that if I have a WG screen and an application which does not support the opt-out protocol or bought into a competing* system, it will be reduced to sRGB while the application and the Where would be a competing system on Linux? screen actually could do WG ... but the delete icon in dolphin looks correct? That is correctly described and expected behaviour as developers said. Next question: do you have approached the Wayland project on this? In case, what do they say? We discussed that with Wayland people and the last spec revision was adapted to meet their concerns. So the transition from X Color Management to W(ayland) Color Management should be relativele smooth. http://lists.freedesktop.org/archives/openicc/2012q1/004595.html http://www.oyranos.org/2012/02/x-color-management-0-4-draft1 *semi OT sidenote: This is btw. sth. I do not like at all. Xorg and fdo do not have the market share -esp. in that market- to afford two competing color management systems. I have no idea about the technical, conceptual and maybe religious differences, but would suggest to iron that out by all means if you ever want usable CM on this Architecture. What other substantial proposals or discussions do you have in mind? As far as I can see there was no publically discussed *competing* concept of substance ever brought to the attention of the graphics community. We only have read some nebulous and non technical statements on the typical level of marketing. OpenICC [1] is the fd.o place to discuss such CM stuff or at least the Xorg email list. In both I am active. I will surely continue to present and discuss the idea with users and developers in various events. kind regards Kai-Uwe Behrmann -- www.oyranos.org [1] http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012
Re: [GSoC] KWin colour management
Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking: Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin mgraess...@kde.org: A fully color corrected compositor seems feasible to me I'm atm. not even sure about that. I might be utterly wrong, but my impression is that the xvidmode extension can correct screens (eg. xcalib loads icc profiles), so a screen wide color xvidmode gamma ramps are per channel curves. These are very limited compared to ICC based colour correction. Those gamma curves provide better gray balance and potentialy white point adjustment. But they do not describe colour primaries shifts or other more complex distortions. Gamma curves must be taken into account for ICC profiles. But detailed characterisation of device colorimetry happens usualy in ICC profiles. correcting compositor would be only required to fix multiscreen (not multihead) setups which i frankly consider no case either, because a full correction would just mean to restrict the WG screen to the SRGB one The X Color Management spec requires per window colour correction for base line implementations. Thus it is possible to specify an source space other than sRGB. (yesno?!), what doesn't much sound like a great achievement to me (and is simply no case in at least the professional context. You don't purchase _one_ WG screen to use it -restricted- alongside your SRGB screen, but just purchase two WG screens and give away the SRGB one to one of your employees at home or whatever) exactly. Thats why opting out of colour management and being able to specify a intermediate colour profile is a good thing. Cheers, Thomas kind regards Kai-Uwe
Re: [GSoC] KWin colour management
On Wed, Mar 21, 2012 at 8:39 AM, Kai-Uwe Behrmann k...@gmx.de wrote: Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking: Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin mgraess...@kde.org: A fully color corrected compositor seems feasible to me I'm atm. not even sure about that. I might be utterly wrong, but my impression is that the xvidmode extension can correct screens (eg. xcalib loads icc profiles), so a screen wide color xvidmode gamma ramps are per channel curves. These are very limited compared to ICC based colour correction. Those gamma curves provide better gray balance and potentialy white point adjustment. But they do not describe colour primaries shifts or other more complex distortions. Gamma curves must be taken into account for ICC profiles. But detailed characterisation of device colorimetry happens usualy in ICC profiles. This may be an ignorant question, but can xvidmode be extended to offer more complex correction? -Todd
Re: Re: [GSoC] KWin colour management
On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote: There is more into it: first of all KWin currently does not distinguish between screens during rendering. To properly have screen aware color correction the complete compositor has to be made screen aware. The repaint loop has to be As a side note, during the last CLT fair there was the idea brought up, to place ICC colour correction inside a KWin plugin. Is that recommendable? I'm kind of confused by this question: I just wrote that the compositor is not screen aware. How should a plugin be able to handle screen aware rendering if the core does not? split into multiple rendering passes - one for each screen. This is quite a change in the way how KWin renders, but might be a useful change. As a second step all fragment shaders need to be adjusted to do the color Which shaders and adjusted for what specifically? May you point us to them, in order to get an idea? http://quickgit.kde.org/index.php?p=kde-workspace.gita=treef=kwin As KWin renders through shaders and I expect that the screen should always be color corrected the answer is simple: all of them. GSoC completes or not will be judged only by Oyranos. A successfully completed project at Oyranos to write code to KWin does not mean that the code will be merged into KWin. The more we are interested to see the KWin project being involved. Whether a project succeeds or not does not depend on KWin being involved in this project. It's the mentor and student who have to ensure to develop code acceptable to the requirements of KWin development. Given recent discussions on this mailinglist about Oyranos and colord I am very unsure whether I want any color management relevant code in KWin at the moment. I will definitely not accept any code supporting only one of the two systems and any additional build or run-time dependency to KWin will not be accepted. Has KDE facities to load and apply ICC profiles? ICC support needs at least a colour management module (CMM) like lcms. In general there seems to be agreement that color management has to be done inside the toolkit/application and not inside the compositor. A fully color You are pointing towards osX? Sorry, but what does it have to do with OS X? I think that Qt and any other toolkit will need a not small amount of time to implement a similar engineered colour managed scene graph. Such stuff is certainly deployed inside PDF workflows. But my feeling says, it is a lot of work to get such a beast inside a cross platform Qt layer. Very likely not Qt5. How long would we have to wait for that? 5 years or more realistically 10 years or will that happen at all? Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. corrected compositor seems feasible to me, but one where some applications need to start opting-out of being color corrected is nothing I want to see in KWin as it adds significant complexity and overhead to the rendering process. Opting out of colour management is a pre condition to do * raw measurements, such as for ICC profile generation * application side specialised colour correction It needs to internally store the colour transform per window. If there is none, then there is no conversion needed. in other words: it affects all windows and adds significant rendering overhead to it as it has to be decided whether there has to be a conversion or not. That's exactly what I wrote and why I don't want the complexity inside KWin. This is something the Oyranos community has to decide on how they want to have that handled. Oyranos is only one colour management project inside the OpenICC community. It is true that I am much behind the concept of implicite display ICC colour correction. But surely more people have a interest in that concept being deployed inside KDE. I'm not sure what you want to tell me with this last sentence. To me it's totally irrelevant what people want if I have to do a technical decision. I also want many things but don't get them :-) Kind Regards Martin Gräßlin KWin Maintainer signature.asc Description: This is a digitally signed message part.
Re: [GSoC] KWin colour management
Am 21.03.12, 18:20 +0100 schrieb Martin Gräßlin: On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote: There is more into it: first of all KWin currently does not distinguish between screens during rendering. To properly have screen aware color correction the complete compositor has to be made screen aware. The repaint loop has to be As a side note, during the last CLT fair there was the idea brought up, to place ICC colour correction inside a KWin plugin. Is that recommendable? I'm kind of confused by this question: I just wrote that the compositor is not screen aware. How should a plugin be able to handle screen aware rendering if the core does not? I can only speak from the existing colour server plugin. It does handle per screen colour correction regardless of support in the actual used compositor. Of course it needs a n-screen loop for drawing all screen overlapping windows. split into multiple rendering passes - one for each screen. This is quite a change in the way how KWin renders, but might be a useful change. As a second step all fragment shaders need to be adjusted to do the color Which shaders and adjusted for what specifically? May you point us to them, in order to get an idea? http://quickgit.kde.org/index.php?p=kde-workspace.gita=treef=kwin As KWin renders through shaders and I expect that the screen should always be color corrected the answer is simple: all of them. A 3D texture lookup is done usually only once inside the pipeline. The plugins inside the kwin/effects path might be used simultaneously. So placing a additional 3D texture lookup into each of those plugins would lead to unwanted multiple colour corrections. GSoC completes or not will be judged only by Oyranos. A successfully completed project at Oyranos to write code to KWin does not mean that the code will be merged into KWin. The more we are interested to see the KWin project being involved. Whether a project succeeds or not does not depend on KWin being involved in this project. It's the mentor and student who have to ensure to develop code acceptable to the requirements of KWin development. Personally I would not make inclusion of code a pre condition for the success of such a project. Upstream inclusion of code is a high goal for contributors anywhere. Not many GSoC projects reach that immediately. Given recent discussions on this mailinglist about Oyranos and colord I am very unsure whether I want any color management relevant code in KWin at the moment. I will definitely not accept any code supporting only one of the two systems and any additional build or run-time dependency to KWin will not be accepted. Has KDE facities to load and apply ICC profiles? ICC support needs at least a colour management module (CMM) like lcms. In general there seems to be agreement that color management has to be done inside the toolkit/application and not inside the compositor. A fully color You are pointing towards osX? Sorry, but what does it have to do with OS X? osX is to my current knowledge the only desktop environment with colour correction to the whole screen. That could be seen as a hint towards colour management has to be done inside the toolkit. I think that Qt and any other toolkit will need a not small amount of time to implement a similar engineered colour managed scene graph. Such stuff is certainly deployed inside PDF workflows. But my feeling says, it is a lot of work to get such a beast inside a cross platform Qt layer. Very likely not Qt5. How long would we have to wait for that? 5 years or more realistically 10 years or will that happen at all? Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. The X Color Management spec allows for opt-out inside compositors. I think to demonstrated you that on osC. corrected compositor seems feasible to me, but one where some applications need to start opting-out of being color corrected is nothing I want to see in KWin as it adds significant complexity and overhead to the rendering process. Opting out of colour management is a pre condition to do * raw measurements, such as for ICC profile generation * application side specialised colour correction It needs to internally store the colour transform per window. If there is none, then there is no conversion needed. in other words: it affects all windows and adds significant rendering overhead to it as it has to be decided whether there has to be a conversion or not. That's exactly what I wrote and why I don't want the complexity inside KWin. What
Re: Re: [GSoC] KWin colour management
On Wednesday 21 March 2012 19:14:51 Kai-Uwe Behrmann wrote: Am 21.03.12, 18:20 +0100 schrieb Martin Gräßlin: On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote: There is more into it: first of all KWin currently does not distinguish between screens during rendering. To properly have screen aware color correction the complete compositor has to be made screen aware. The repaint loop has to be As a side note, during the last CLT fair there was the idea brought up, to place ICC colour correction inside a KWin plugin. Is that recommendable? I'm kind of confused by this question: I just wrote that the compositor is not screen aware. How should a plugin be able to handle screen aware rendering if the core does not? I can only speak from the existing colour server plugin. It does handle per screen colour correction regardless of support in the actual used compositor. Of course it needs a n-screen loop for drawing all screen overlapping windows. I assume you speek of the plugin for Compiz. Please note that KWin has a different rendering architecture which needs to be adjusted. It is pretty much irrelevant how it works on Compiz for the usage inside KWin. As I have written now multiple times: KWin does not support rendering per screen. split into multiple rendering passes - one for each screen. This is quite a change in the way how KWin renders, but might be a useful change. As a second step all fragment shaders need to be adjusted to do the color Which shaders and adjusted for what specifically? May you point us to them, in order to get an idea? http://quickgit.kde.org/index.php?p=kde-workspace.gita=treef=kwin As KWin renders through shaders and I expect that the screen should always be color corrected the answer is simple: all of them. A 3D texture lookup is done usually only once inside the pipeline. The plugins inside the kwin/effects path might be used simultaneously. So placing a additional 3D texture lookup into each of those plugins would lead to unwanted multiple colour corrections. I think you do not know how KWin's rendering works. In a simplistic way: a window is rendered to the screen through a shader. At runtime KWin decides which shader to be used. As by that there is always only one active shader, so to have color correction it has to be added to all shaders which render windows/textures/colors. This is different to any experience you might have from Compiz 0.8. There the screen was not rendered with shaders but plugins could use shaders. GSoC completes or not will be judged only by Oyranos. A successfully completed project at Oyranos to write code to KWin does not mean that the code will be merged into KWin. The more we are interested to see the KWin project being involved. Whether a project succeeds or not does not depend on KWin being involved in this project. It's the mentor and student who have to ensure to develop code acceptable to the requirements of KWin development. Personally I would not make inclusion of code a pre condition for the success of such a project. Upstream inclusion of code is a high goal for contributors anywhere. Not many GSoC projects reach that immediately. If you don't aim for inclusion into KWin, I seriously do not see why such a project is needed. Given the changes inside KWin I doubt any of the code could be reused let's say a year later. Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) On the other hand, Xorg architect Jim Getty told me, that compositors are the right places for colour correction. that might be quite true, but not if apps want to opt-out. The X Color Management spec allows for opt-out inside compositors. I think to demonstrated you that on osC. and I think I explained to you why I don't think that's a good idea for KWin :-) corrected compositor seems feasible to me, but one where some applications need to start opting-out of being color corrected is nothing I want to see in KWin as it adds significant complexity and overhead to the rendering process. Opting out of colour management is a pre condition to do * raw measurements, such as for ICC profile generation * application side specialised colour correction It needs to internally store the colour transform per window. If there is none, then there is no conversion needed. in other words: it affects all windows and adds significant rendering overhead to it as it has to be decided whether there has to be a conversion or not. That's
Re: [GSoC] KWin colour management
On Wednesday 21 March 2012 20.34.00 Martin Gräßlin wrote: Personally I would not make inclusion of code a pre condition for the success of such a project. Upstream inclusion of code is a high goal for contributors anywhere. Not many GSoC projects reach that immediately. If you don't aim for inclusion into KWin, I seriously do not see why such a project is needed. Given the changes inside KWin I doubt any of the code could be reused let's say a year later. Thats a very good point, one that may not be quick to grasp by potential gsoc students. This point should be made very clear otherwise I fear people might get very dissapointed if their work ends up being discarded. Discarded because the initial setup wasn't thought through. I would say that the core aim of the GSOC project should be inclusion in kwins tree for any KDE people to spent any time on this or even support it. Otherwise it would be unfair to various people. Like the student and the hosting org and also to the kde volunteers helping with it. Do you have any references showing that it is impossible to add color correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base technical decisions on my feeling says. That would mean colour management appears earliest inside Qt 6. But it is at the moment not clear if that happens at all. Any proof for these bold statements? Anything from Qt where I can see that this is the case (also for Wayland)? Remember nobody wants to develop for X anymore ;-) Color management in Qt is a bit of a weird statement; first of all, support is already possible as Krita proves. Second, I doubt that 94% of the widgets actually need color correction of the type that kwin could provide. Who cares that their text edits and their buttons are color correct? Its only for canvas-like widgets that this is relevant, and apps have that option already by linking to LCMS. So, KWin support would just be a shortcut. A one-stop solution to make all apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its a shortcut. So please keep treating it as such. When people talk about the toolkit adding support its more about convenience APIs. Think a QPainter method to set a color transform to do correction on following draws. When people want support in the toolkit, they want the color selector widget, the print preview widget etc, that come with Qt to natively use the monitor profile. Last, they want the printing to take color management into account. All of those are possible and likely even welcomed in Qt. The only thing is that someone has to actually do it. So saying that it won't happen in Qt6 is a self-fulfilling wish, and I feel its not very fair to plant that doubt in peoples minds. What would KWin people suggest how and where to place this feature near KWin? Well the question is whether such a feature is needed at all. I would say: * either correct the whole screen * or let the windows handle it Now it becomes quite simple: there's an app doing color correction itself. In that case we can safely assume that the user wants the app to take care - compositor does no longer color correct the screen. There is no application taking care of it: compositor renders the whole screen. Sounds good to me. -- Thomas Zander
Re: [GSoC] KWin colour management
On Sunday 18 March 2012 20:01:01 Casian Andrei wrote: Hello, taking it to the KWin mailinglist as that's the relevant list in case this proposal would be accepted. First of all thanks for considering doing a GSoC project around KWin. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. This would probably only be part of it. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. There is more into it: first of all KWin currently does not distinguish between screens during rendering. To properly have screen aware color correction the complete compositor has to be made screen aware. The repaint loop has to be split into multiple rendering passes - one for each screen. This is quite a change in the way how KWin renders, but might be a useful change. As a second step all fragment shaders need to be adjusted to do the color correction. This has to be done extremely efficient. This is a rather critical code path especially for low-end hardware (think of old Intel GPUs). Given the constraints of the GPUs a dynamic feature activation is not possible. What is in general important to know is that we have not had the best experience with GSoC students doing work on the core of KWin. Given that I proposed guidelines for future feature additions to KWin by non-core developers [1]. Furthermore I want to mention that the project would at max be co-mentored from the KWin team. The slot is provided by the Oyranos community and not by KDE. This means that the main mentor will be at Oyranos and also whether the GSoC completes or not will be judged only by Oyranos. A successfully completed project at Oyranos to write code to KWin does not mean that the code will be merged into KWin. Given recent discussions on this mailinglist about Oyranos and colord I am very unsure whether I want any color management relevant code in KWin at the moment. I will definitely not accept any code supporting only one of the two systems and any additional build or run-time dependency to KWin will not be accepted. In general there seems to be agreement that color management has to be done inside the toolkit/application and not inside the compositor. A fully color corrected compositor seems feasible to me, but one where some applications need to start opting-out of being color corrected is nothing I want to see in KWin as it adds significant complexity and overhead to the rendering process. This is something the Oyranos community has to decide on how they want to have that handled. Kind Regards Martin Gräßlin KWin Maintainer [1] http://community.kde.org/KWin/Mission_Statement
[GSoC] KWin colour management
Hello, I am a final year undergraduate student at the Polytechnic University of Bucharest, Automation and Computers Faculty. I am interested in the Compositor Colour Management idea from OpenSUSE. It looks like something I would enjoy doing. I have acceptable C / C ++ skills and lots of experience with OpenGL. I am also familiar with Qt. Regarding shaders, I wrote a couple about 2 years ago for an old project, and I still know how they work, so it would be easy for me to remember. Last GSoC I worked on an OpenGL interface for VLC, and 2 years ago I worked on capture support in Phonon. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. But I am still unsure and I don't have an exact image in mind about what needs to be done. Clearly, more exploration is needed. I don't know what to concentrate on - looking around in KWin / Compiz code, concentrating on libXcm and the X Color Management spec, reading more about Oyranos and colour management in general? I tried the Oyranos colour management LiveCD and I saw it doing the correction magic, but unfortunately I was unable to get compiz working - with the open source drivers it didn't start because of missing glx_ext_texture_from_pixmap extension, and there were problems with the ati drivers - after installing them, the root visual was not a GL visual (or something like that), and if I tried to do some configuration with Catalyst, then X froze together with the system (nothing new for me, that's why I am sticking to the open source drivers). At least I know ICC profiles for both my monitors were found, by monitoring with QcmsEvents. Best regards, Casian
Re: [GSoC] KWin colour management
Thanks for posting here. Am 18.03.12, 20:01 +0200 schrieb Casian Andrei: Hello, I am a final year undergraduate student at the Polytechnic University of Bucharest, Automation and Computers Faculty. I am interested in the Compositor Colour Management idea from OpenSUSE. It looks like something I would enjoy doing. Given that colour management inside open source toolkits is a very very long outstanding issue, and we are still at the beginning with that, it is unlikely that Qt5 will allow to colour manage _all_ it's widgets by default. That means, we will see only few graphics applications to do ICC colour correction themself. Consequently most other desktop applications and areas will look different on each monitor. In my opinion, the most easy path towards working end to end colour management inside KDE is to assume sRGB for all non colour aware applications and do colour correction unquestioned. That concept is worked out on OpenICC and used and checked on a daily base with CompICC. So it is no longer a experimental feature. In comparision, the concept to colour manage unaware colour content is as well common practise inside Linux and other OS printing paths. Ghostscript and likely Poppler will or do already colour convert the mass of todays /DeviceRGB colour unquestioned. They will implicitely assume that these colours to be meant as sRGB. I suggest we should follow that route for displaying inside KWin and improve colour useability on the KDE desktop. I have acceptable C / C ++ skills and lots of experience with OpenGL. I am also familiar with Qt. Regarding shaders, I wrote a couple about 2 years ago for an old project, and I still know how they work, so it would be easy for me to remember. Last GSoC I worked on an OpenGL interface for VLC, and 2 years ago I worked on capture support in Phonon. I need your guidance in order to create a decent proposal. I understand the project will involve implementing the colour management features in KWin. As the idea suggests, this would imply making KWin handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms. The idea behind these two atoms is to enable per window colour correction, which is relatively easy implemented. In a first step a window manager can be enabled with that feature. It is completely backward compatible. Graphic applications can be updated step by step to take advantage of the new ICC support by implementing the X Color Management protocol. They will profit by getting multi monitor aware very fast and power efficient colour correction with the smallest effort. Some few applications exist already, which deploy this scheme. Qt or KDE widgets can be created to share common code among such apps. Today I documented myself about colour management in general, and how it's done in Linux. I also read about ICC, Oyranos, X color management and related things. Now I'm not completely in the dark as before. I looked around in the KWin code and I found the area of interest - the compositor part, more specifically KWin::SceneOpenGL. Since shaders will be needed, it looks like some custom shaders of type KWin::ShaderManager::ColorShader would be able to do the job. Please correct me if this is wrong. But I am still unsure and I don't have an exact image in mind about what needs to be done. Clearly, more exploration is needed. I don't know what to concentrate on - looking around in KWin / Compiz code, concentrating on libXcm and the X Color Management spec, reading more about Oyranos and colour management in general? I tried the Oyranos colour management LiveCD and I saw it doing the correction magic, but unfortunately I was unable to get compiz working - with the open source drivers it didn't start because of missing glx_ext_texture_from_pixmap extension, and there were problems with the ati drivers - after installing them, the root visual was not a GL visual (or something like that), and if I tried to do some configuration with Catalyst, then X froze together with the system (nothing new for me, that's why I am sticking to the open source drivers). At least I know ICC profiles for both my monitors were found, by monitoring with QcmsEvents. Best regards, Casian kind regards Kai-Uwe -- www.oyranos.org
