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