Re: [RFC PATCH v2 0/6] Initial per-surface color management
Am 29.10.2014 um 20:15 schrieb Niels Ole Salscheider: On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote: Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider: The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. I had a discussion regarding this with Zoxc on the IRC channel. Does it make sense to have a surface that is displayed uncorrected on multiple outputs with different output profiles? If so then this is not enough to detect that no color conversion should be applied at all. For measuring the colorimetric performance of outputs, for testing and scalability, it appears the easiest to have a colormanagement-off switch. On osX, without such switch, the mechanism to attach the monitor profile to the input image brings headache to developers and this workaround does not work reliably. Sure, I introduced the possibility to disable color correction of a surface for these use-cases in my first proposal. But is it really enough to just not apply color corrections to a surface? Or would this use-case require to deactivate color correction completely, as argued by John Kåre Alsaker? I can only guess what the motivation for a per output switch-off might be: * graphic cards video lut handling * compositing space triggering * consistency with alpha blending behaviour for stacked transparent surfaces with and without CM enabled * effects on top of windows (sepia, etc.) Some of the above mentioned mechanisms are not easy to integrate. So the best is to have access to each mechanism by an separate API and let applications handle them on need. For compositing might arise the need to switch off the compositing space. So a transparent widget on top of a graphics application will not make the case to touch the rgb numbers, except for the blending areas of course. Further the transparent widget can overlap in parts the CM-off widget and normal areas at the same time. So the compositing of the different areas has to be handled separately. Given that for different outputs different colour conversions are needed, that feature appears not that far stretched. The user experience will be relatively smooth. In contrary, a global CM-off will have many side effects, which make potentially a unwanted user experience for Yuv video, or other widgets, which should not be affected on desktops. On handheld systems, that is less of concern. In the latter case, it might be better to add another protocol that allows such tools to temporarily deactivate any color conversions... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2 0/6] Initial per-surface color management
On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote: Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider: The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. I had a discussion regarding this with Zoxc on the IRC channel. Does it make sense to have a surface that is displayed uncorrected on multiple outputs with different output profiles? If so then this is not enough to detect that no color conversion should be applied at all. For measuring the colorimetric performance of outputs, for testing and scalability, it appears the easiest to have a colormanagement-off switch. On osX, without such switch, the mechanism to attach the monitor profile to the input image brings headache to developers and this workaround does not work reliably. Sure, I introduced the possibility to disable color correction of a surface for these use-cases in my first proposal. But is it really enough to just not apply color corrections to a surface? Or would this use-case require to deactivate color correction completely, as argued by John Kåre Alsaker? In the latter case, it might be better to add another protocol that allows such tools to temporarily deactivate any color conversions... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2 0/6] Initial per-surface color management
Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider: The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. I had a discussion regarding this with Zoxc on the IRC channel. Does it make sense to have a surface that is displayed uncorrected on multiple outputs with different output profiles? If so then this is not enough to detect that no color conversion should be applied at all. For measuring the colorimetric performance of outputs, for testing and scalability, it appears the easiest to have a colormanagement-off switch. On osX, without such switch, the mechanism to attach the monitor profile to the input image brings headache to developers and this workaround does not work reliably. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2 0/6] Initial per-surface color management
The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. I had a discussion regarding this with Zoxc on the IRC channel. Does it make sense to have a surface that is displayed uncorrected on multiple outputs with different output profiles? If so then this is not enough to detect that no color conversion should be applied at all. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC PATCH v2 0/6] Initial per-surface color management
It has been a few months since I sent the first version of the patches adding per-surface color management (http://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html). I finally got around to addressing some of the issues of the first proposal. Color profiles are now represented by protocol objects. They can be created by passing a file descriptor of the profile to the compositor instead of by passing the data directly. The compositor then uses the signature of the passed profile (md5 sum) to make sure that each profile is stored only once. The attached profile is now double-buffered. The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. This is not enough for color profiling tools but these will need another protocol that also allows to reset the hardware LUTs. In the last discussion, Pekka Paalanen asked if it is reasonable to expect that each compositor that wants to provide color correction implements the complete protocol or if it would be enough for simple compositors to only provide the output color spaces. However, color management with such a simplified protocol gets very difficult for the clients when there are multiple outputs. Another point is that the client side implementation gets much less complex when using the full protocol together with sub-surfaces so that it becomes more likely to see widespread use of this protocol. Finally, the required effort to support the full protocol in the compositor is not that high. I therefore think that it is best to require to implement support for the full protocol. The implementation of the color conversion is still not perfect. It still uses an LUT with 8 bit per color, for example. John Kåre Alsaker however has some patches that would help here like the support for desktop OpenGL. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
