Discussion:
[RFC wayland-protocols] Color management protocol
(too old to reply)
Niels Ole Salscheider
2016-11-19 16:29:19 UTC
Permalink
Hello,

it has been some time since I proposed the first two RFCs for a color
management protocol in weston. You can find the old discussions here:

https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html

During the discussion of the second RFC it became clear that color correction
was out of scope for weston at that time.
In the meantime wayland-protocols was split from weston and libweston was
created. Several wayland compositors start to see everyday usage and wide-gamut
screens became more common so that color management becomes more important.

Therefore I think that the situation has changed and I'd like to propose this
protocol for inclusion in wayland-protocols again.
What do you think?

Ole

Niels Ole Salscheider (1):
Add the color-management protocol

Makefile.am | 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 136 +++++++++++++++++++++
3 files changed, 141 insertions(+)
create mode 100644 unstable/color-management/README
create mode 100644 unstable/color-management/color-management-unstable-v1.xml
--
2.10.2
Niels Ole Salscheider
2016-11-19 16:29:20 UTC
Permalink
Signed-off-by: Niels Ole Salscheider <***@salscheider-online.de>
---
Makefile.am | 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 136 +++++++++++++++++++++
3 files changed, 141 insertions(+)
create mode 100644 unstable/color-management/README
create mode 100644 unstable/color-management/color-management-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..ff435d5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/color-management/color-management-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/color-management/README b/unstable/color-management/README
new file mode 100644
index 0000000..3bd3e6c
--- /dev/null
+++ b/unstable/color-management/README
@@ -0,0 +1,4 @@
+Color management protocol
+
+Maintainers:
+Niels Ole Salscheider <***@salscheider-online.de>
diff --git a/unstable/color-management/color-management-unstable-v1.xml b/unstable/color-management/color-management-unstable-v1.xml
new file mode 100644
index 0000000..f2bb3f6
--- /dev/null
+++ b/unstable/color-management/color-management-unstable-v1.xml
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="color_management_unstable_v1">
+
+ <copyright>
+ Copyright © 2014-2016 Niels Ole Salscheider
+
+ Permission to use, copy, modify, distribute, and sell this
+ software and its documentation for any purpose is hereby granted
+ without fee, provided that the above copyright notice appear in
+ all copies and that both that copyright notice and this permission
+ notice appear in supporting documentation, and that the name of
+ the copyright holders not be used in advertising or publicity
+ pertaining to distribution of the software without specific,
+ written prior permission. The copyright holders make no
+ representations about the suitability of this software for any
+ purpose. It is provided "as is" without express or implied
+ warranty.
+
+ THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+ THIS SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_color_management_v1" version="1">
+ <description summary="allows attaching a color space to a wl_surface">
+ This interface allows attaching a color space to a wl_surface. The
+ compositor uses this information to display the colors correctly.
+ For this, the compositor converts any attached surfaces to the blending
+ color space before performing the blending operations. After blending,
+ the output surface is converted to the color space of the output device.
+ This interface also provides requests for the sRGB and the blending color
+ space. It further allows creation of a color space from an ICC profile.
+ The client is informed by an event if the color space of one of the
+ outputs changes.
+ </description>
+
+ <request name="set_colorspace">
+ <description summary="set the color space of a wl_surface">
+ With this request, the color space of a wl_surface can be set.
+ The sRGB colorspace is attached to a surface before set_colorspace is
+ called for the first time.
+ </description>
+ <arg name="surface" type="object" interface="wl_surface" />
+ <arg name="colorspace" type="object" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="colorspace_from_fd">
+ <description summary="creates a color space from an ICC profile">
+ This request allows to create a zwp_colorspace_v1 object from an ICC
+ profile. The fd argument is the file descriptor to the ICC profile (ICC
+ V2 or V4).
+ </description>
+ <arg name="fd" type="fd" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="output_colorspace">
+ <description summary="returns the color space for the requested output">
+ This request returns a zwp_colorspace_v1 object for the requested
+ output. A client can use this when it does not want its surfaces to be
+ color-corrected. In this case it can attach the color space of its main
+ output to its surfaces.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="srgb_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_1 object for the sRGB color
+ space. The sRGB color space is initially attached to all surfaces.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="blending_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_v1 object for the blending color
+ space of the compositor. All surfaces are converted by the compositor
+ to the blending color space before the blending operations. Once the
+ blending is performed, a further color conversion to the output color
+ spaces is carried out by the compositor.
+ A client should render in the blending color space returned by this
+ request if it does any color conversion on its own. This allows the
+ compositor to skip the color conversion to the blending color space.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <event name="output_colorspace_changed">
+ <description summary="tell the client what color space an output has">
+ This event will be sent when the color space of an output is changed.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ </event>
+
+ <enum name="error">
+ <entry name="invalid_profile" value="0"
+ summary="the passed icc data is invalid" />
+ </enum>
+ </interface>
+
+ <interface name="zwp_colorspace_v1" version="1">
+ <description summary="represents a color space">
+ This interface represents a color space that can be attached to surfaces.
+ It is used by the zwp_color_management_v1 interface.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroys the zwp_colorspace_v1 object">
+ Informs the server that the client will not be using this protocol
+ object anymore.
+ </description>
+ </request>
+
+ <request name="get_profile_fd">
+ <description summary="get a file descriptor to the profile data">
+ This request will cause a profile_fd event that returns a file
+ descriptor to the ICC profile data of this colorspace.
+ </description>
+ </request>
+
+ <event name="profile_data">
+ <description summary="file descriptor to the profile data">
+ This event occurs after a get_profile_fd request and returns the file
+ descriptor to the ICC profile data of this colorspace.
+ </description>
+ <arg name="fd" type="fd" />
+ </event>
+ </interface>
+</protocol>
--
2.10.2
Niels Ole Salscheider
2016-11-26 09:52:32 UTC
Permalink
Is there a way to determine if two zwp_colorspace objects are actually the
same?
The ICC profiles to which the zwp_colorspace objects point can be compared
easily: Each ICC profile contains an unique 128 bit fingerprint in the header so
that only this fingerprint has to be compared.
Do you think that this is enough or do you want this information to be
duplicated in the zwp_colorspace object?
I can imagine clients being interested in whether or not the output
colorspace is sRGB, and whether or not the blending color space is
sRGB or the output space.
On Sat, Nov 19, 2016 at 8:29 AM, Niels Ole Salscheider
Post by Niels Ole Salscheider
---
Makefile.am | 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 136
+++++++++++++++++++++ 3 files changed, 141 insertions(+)
create mode 100644 unstable/color-management/README
create mode 100644
unstable/color-management/color-management-unstable-v1.xml>
diff --git a/Makefile.am b/Makefile.am
index e693afa..ff435d5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols =
\>
unstable/tablet/tablet-unstable-v2.xml
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
\
+ unstable/color-management/color-management-unstable-v1.xml
\>
$(NULL)
stable_protocols =
\>
diff --git a/unstable/color-management/README
b/unstable/color-management/README new file mode 100644
index 0000000..3bd3e6c
--- /dev/null
+++ b/unstable/color-management/README
@@ -0,0 +1,4 @@
+Color management protocol
+
diff --git a/unstable/color-management/color-management-unstable-v1.xml
b/unstable/color-management/color-management-unstable-v1.xml new file
mode 100644
index 0000000..f2bb3f6
--- /dev/null
+++ b/unstable/color-management/color-management-unstable-v1.xml
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="color_management_unstable_v1">
+
+ <copyright>
+ Copyright © 2014-2016 Niels Ole Salscheider
+
+ Permission to use, copy, modify, distribute, and sell this
+ software and its documentation for any purpose is hereby granted
+ without fee, provided that the above copyright notice appear in
+ all copies and that both that copyright notice and this permission
+ notice appear in supporting documentation, and that the name of
+ the copyright holders not be used in advertising or publicity
+ pertaining to distribution of the software without specific,
+ written prior permission. The copyright holders make no
+ representations about the suitability of this software for any
+ purpose. It is provided "as is" without express or implied
+ warranty.
+
+ THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+ THIS SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_color_management_v1" version="1">
+ <description summary="allows attaching a color space to a wl_surface">
+ This interface allows attaching a color space to a wl_surface. The
+ compositor uses this information to display the colors correctly.
+ For this, the compositor converts any attached surfaces to the
blending + color space before performing the blending operations.
After blending, + the output surface is converted to the color space
of the output device. + This interface also provides requests for
the sRGB and the blending color + space. It further allows creation
of a color space from an ICC profile. + The client is informed by an
event if the color space of one of the + outputs changes.
+ </description>
+
+ <request name="set_colorspace">
+ <description summary="set the color space of a wl_surface">
+ With this request, the color space of a wl_surface can be set.
+ The sRGB colorspace is attached to a surface before
set_colorspace is + called for the first time.
+ </description>
+ <arg name="surface" type="object" interface="wl_surface" />
+ <arg name="colorspace" type="object" interface="zwp_colorspace_v1"
/> + </request>
+
+ <request name="colorspace_from_fd">
+ <description summary="creates a color space from an ICC profile">
+ This request allows to create a zwp_colorspace_v1 object from an
ICC + profile. The fd argument is the file descriptor to the ICC
profile (ICC + V2 or V4).
+ </description>
+ <arg name="fd" type="fd" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="output_colorspace">
+ <description summary="returns the color space for the requested
output"> + This request returns a zwp_colorspace_v1 object for the
requested + output. A client can use this when it does not want
its surfaces to be + color-corrected. In this case it can attach
the color space of its main + output to its surfaces.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="srgb_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_1 object for the sRGB color
+ space. The sRGB color space is initially attached to all surfaces.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="blending_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_v1 object for the blending
color + space of the compositor. All surfaces are converted by the
compositor + to the blending color space before the blending
operations. Once the + blending is performed, a further color
conversion to the output color + spaces is carried out by the
compositor.
+ A client should render in the blending color space returned by
this + request if it does any color conversion on its own. This
allows the + compositor to skip the color conversion to the
blending color space. + </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <event name="output_colorspace_changed">
+ <description summary="tell the client what color space an output
has"> + This event will be sent when the color space of an output
is changed. + </description>
+ <arg name="output" type="object" interface="wl_output" />
+ </event>
+
+ <enum name="error">
+ <entry name="invalid_profile" value="0"
+ summary="the passed icc data is invalid" />
+ </enum>
+ </interface>
+
+ <interface name="zwp_colorspace_v1" version="1">
+ <description summary="represents a color space">
+ This interface represents a color space that can be attached to
surfaces. + It is used by the zwp_color_management_v1 interface.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroys the zwp_colorspace_v1 object">
+ Informs the server that the client will not be using this protocol
+ object anymore.
+ </description>
+ </request>
+
+ <request name="get_profile_fd">
+ <description summary="get a file descriptor to the profile data">
+ This request will cause a profile_fd event that returns a file
+ descriptor to the ICC profile data of this colorspace.
+ </description>
+ </request>
+
+ <event name="profile_data">
+ <description summary="file descriptor to the profile data">
+ This event occurs after a get_profile_fd request and returns the
file + descriptor to the ICC profile data of this colorspace.
+ </description>
+ <arg name="fd" type="fd" />
+ </event>
+ </interface>
+</protocol>
--
2.10.2
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Graeme Gill
2016-12-08 02:32:55 UTC
Permalink
Niels Ole Salscheider wrote:

Hi,
Post by Niels Ole Salscheider
The ICC profiles to which the zwp_colorspace objects point can be compared
easily: Each ICC profile contains an unique 128 bit fingerprint in the header so
that only this fingerprint has to be compared.
actually, this isn't true. The MD5 fingerprint value was only introduced
in ICC V4, and so is not present in ICC V2 profiles. Even in V4
profiles, it is recommended rather than mandatory, so can't be relied upon.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-20 01:45:30 UTC
Permalink
On Mon, 19 Dec 2016 10:07:31 +0100 Niels Ole Salscheider
On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
---
Makefile.am | 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 136
++++++++++++++++++++>
+ 3 files changed, 141 insertions(+)
create mode 100644 unstable/color-management/README
create mode 100644
unstable/color-management/color-management-unstable-v1.xml>
diff --git a/Makefile.am b/Makefile.am
index e693afa..ff435d5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols
= \
unstable/tablet/tablet-unstable-v2.xml
\ unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
\ +
unstable/color-management/color-management-unstable-v1.xml
\ $(NULL)
stable_protocols
= \ diff
--git a/unstable/color-management/README
b/unstable/color-management/README new file mode 100644 index
0000000..3bd3e6c
--- /dev/null
+++ b/unstable/color-management/README
@@ -0,0 +1,4 @@
+Color management protocol
+
diff --git a/unstable/color-management/color-management-unstable-v1.xml
b/unstable/color-management/color-management-unstable-v1.xml new file mode
100644 index 0000000..f2bb3f6
--- /dev/null
+++ b/unstable/color-management/color-management-unstable-v1.xml
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="color_management_unstable_v1">
+
+ <copyright>
+ Copyright © 2014-2016 Niels Ole Salscheider
+
+ Permission to use, copy, modify, distribute, and sell this
+ software and its documentation for any purpose is hereby granted
+ without fee, provided that the above copyright notice appear in
+ all copies and that both that copyright notice and this permission
+ notice appear in supporting documentation, and that the name of
+ the copyright holders not be used in advertising or publicity
+ pertaining to distribution of the software without specific,
+ written prior permission. The copyright holders make no
+ representations about the suitability of this software for any
+ purpose. It is provided "as is" without express or implied
+ warranty.
+
+ THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+ THIS SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_color_management_v1" version="1">
+ <description summary="allows attaching a color space to a wl_surface">
+ This interface allows attaching a color space to a wl_surface. The
+ compositor uses this information to display the colors correctly.
+ For this, the compositor converts any attached surfaces to the
blending + color space before performing the blending operations.
After blending, + the output surface is converted to the color space
of the output device.
+ This interface also provides requests for the sRGB and the blending color
+ space. It further allows creation of a color space from an ICC
profile. + The client is informed by an event if the color space of
one of the + outputs changes.
+ </description>
+
+ <request name="set_colorspace">
+ <description summary="set the color space of a wl_surface">
+ With this request, the color space of a wl_surface can be set.
+ The sRGB colorspace is attached to a surface before
set_colorspace is + called for the first time.
+ </description>
+ <arg name="surface" type="object" interface="wl_surface" />
+ <arg name="colorspace" type="object" interface="zwp_colorspace_v1"
/> + </request>
+
+ <request name="colorspace_from_fd">
+ <description summary="creates a color space from an ICC profile">
+ This request allows to create a zwp_colorspace_v1 object from an
ICC + profile. The fd argument is the file descriptor to the ICC
profile (ICC
+ V2 or V4).
+ </description>
+ <arg name="fd" type="fd" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <request name="output_colorspace">
+ <description summary="returns the color space for the requested output">
+ This request returns a zwp_colorspace_v1 object for the requested
+ output. A client can use this when it does not want its surfaces to be
+ color-corrected. In this case it can attach the color space of
its
main
+ output to its surfaces.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
this above i wonder if this shoiuld be done this way. does it not expose too
much about an output? what happens when the output changes its colorspace?
imagine it has software controls where it can chnage its mapping or
hardware buttons etc.? shouldnt we just have a list of colorspaces
available (that may change at any time so some kind of event indicating a
change would be needed)?
I think this is useful information and some applications might want to know.
If the output color space changes the compositor will notify the applications
by the output_colorspace_changed event (if it knows about it).
what if the display can do different color profiles for different regions? my
example is yuv colorspace. 601 vs 709 etc. actually can be assigned per hw
plane... they are different colorspaces ... :)
I know that many professional screens have a hardware button to switch color
spaces. This is really useful right now because you can switch to sRGB for
normal desktop usage - otherwise the colors are much too saturated.
But I wish that you can just leave your screen in native/full all the time
with this protocol - the compositor will correct the colors for the normal
desktop applications but you still take advantage of the wide gamut when
viewing images or videos.
ultimately this is the right thing. a compositor would color correct all
content eg srgb by default as with most content then high gammut content can
be "let loose".

but hear me out. i have been thinking. shouldnt the compositor send a list of
colorspaces per SURFACE? if the surface moves from screen to screen it may
adjust that list of colorspaces? if a surface spans multiple screens it may
list all colorspaces that the surface spans?
Post by Niels Ole Salscheider
+ <request name="srgb_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_1 object for the sRGB color
+ space. The sRGB color space is initially attached to all surfaces.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
ok - so srgb is default as it implicitly is now. but is this necessary? if
no actual blending takes place isn't this moot? any surface with a buffer
with alpha i don't think is going to get this fussy...
I'm not sure what your point is. Don't you think that it can be useful to get
an sRGB colorspace object without creating one from an ICC profile?
Post by Niels Ole Salscheider
+ <request name="blending_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_v1 object for the blending color
+ space of the compositor. All surfaces are converted by the
compositor + to the blending color space before the blending
operations. Once the + blending is performed, a further color
conversion to the output color + spaces is carried out by the
compositor.
+ A client should render in the blending color space returned by
this + request if it does any color conversion on its own. This
allows the + compositor to skip the color conversion to the
blending color space. + </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
+
+ <event name="output_colorspace_changed">
+ <description summary="tell the client what color space an output
has"> + This event will be sent when the color space of an output
is changed. + </description>
+ <arg name="output" type="object" interface="wl_output" />
+ </event>
as above. should this be tied to an output at all? ok. so an event. great.
Post by Niels Ole Salscheider
+ <enum name="error">
+ <entry name="invalid_profile" value="0"
+ summary="the passed icc data is invalid" />
+ </enum>
+ </interface>
+
+ <interface name="zwp_colorspace_v1" version="1">
+ <description summary="represents a color space">
+ This interface represents a color space that can be attached to surfaces.
+ It is used by the zwp_color_management_v1 interface.
+ </description>
so... here is my question - shouldn't the colorspace be tired to a buffer?
not a surface? yes. i know. the surface "displays" the buffer... but the
colorspace is intrinsic to the buffer content... right?
I'm not sure, I can see reasons for both. I thought about wl_buffer as the
storage while wl_surface contains transformations that have to be applied.
But the color profile is obviously tied to the pixel values.
well this is up for debate... to my mind it belongs to the buffer imho...
but...?
Post by Niels Ole Salscheider
+ <request name="destroy" type="destructor">
+ <description summary="destroys the zwp_colorspace_v1 object">
+ Informs the server that the client will not be using this protocol
+ object anymore.
+ </description>
+ </request>
+
+ <request name="get_profile_fd">
+ <description summary="get a file descriptor to the profile data">
+ This request will cause a profile_fd event that returns a file
+ descriptor to the ICC profile data of this colorspace.
+ </description>
+ </request>
+
+ <event name="profile_data">
+ <description summary="file descriptor to the profile data">
+ This event occurs after a get_profile_fd request and returns the
file + descriptor to the ICC profile data of this colorspace.
+ </description>
+ <arg name="fd" type="fd" />
+ </event>
+ </interface>
+</protocol>
--
2.10.2
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-20 23:20:57 UTC
Permalink
it's a different mapping of byte1, byte2, byte3 within a pixel to different r,g
and b points in the visible spectrum. :)
It's not though - it's colorimetry, so there is no control
over the visible spectrum - the spectral characteristic is
determined by the display primary spectral characteristics,
and a change in representation/encoding doesn't imply
any change in the primaries. Even the RGB's haven't changed,
because the relationship between RGB <-> YCbCr is fixed
according to a given standard.

Graeme Gill.
Daniel Stone
2016-12-20 16:46:07 UTC
Permalink
Hi,
On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
+ <interface name="zwp_colorspace_v1" version="1">
+ <description summary="represents a color space">
+ This interface represents a color space that can be attached to surfaces.
+ It is used by the zwp_color_management_v1 interface.
+ </description>
so... here is my question - shouldn't the colorspace be tired to a buffer? not
a surface? yes. i know. the surface "displays" the buffer... but the colorspace
is intrinsic to the buffer content... right?
Conceptually, buffer is a good shout, but buffers are hidden from you
in EGL. Given that people will want to do (at least vaguely)
colour-correct GL rendering, that makes surface rather than bufer the
right choice.

Cheers,
Daniel
Carsten Haitzler (The Rasterman)
2016-12-21 00:36:59 UTC
Permalink
Post by Daniel Stone
Hi,
On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
+ <interface name="zwp_colorspace_v1" version="1">
+ <description summary="represents a color space">
+ This interface represents a color space that can be attached to surfaces.
+ It is used by the zwp_color_management_v1 interface.
+ </description>
so... here is my question - shouldn't the colorspace be tired to a buffer?
not a surface? yes. i know. the surface "displays" the buffer... but the
colorspace is intrinsic to the buffer content... right?
Conceptually, buffer is a good shout, but buffers are hidden from you
in EGL. Given that people will want to do (at least vaguely)
colour-correct GL rendering, that makes surface rather than bufer the
right choice.
i actually meant wl_buffer which is really the abstraction on top of these
buffers... ?
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Carsten Haitzler (The Rasterman)
2016-12-21 11:21:50 UTC
Permalink
Hi,
Post by Carsten Haitzler (The Rasterman)
Post by Daniel Stone
so... here is my question - shouldn't the colorspace be tired to a
buffer? not a surface? yes. i know. the surface "displays" the buffer...
but the colorspace is intrinsic to the buffer content... right?
Conceptually, buffer is a good shout, but buffers are hidden from you
in EGL. Given that people will want to do (at least vaguely)
colour-correct GL rendering, that makes surface rather than bufer the
right choice.
i actually meant wl_buffer which is really the abstraction on top of these
buffers... ?
egl_dpy = eglGetPlatformDisplay(...);
egl_cfg = eglChooseConfig(egl_dpy, ...);
egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
(bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
{
(void) gl*();
(bool) eglSwapBuffers();
}
oh yeah. i was not thinking if client is using egl and eglswapbuffers is hiding
everything. i was thinking clients explicitly sending buffers.
At no point does an EGL client ever come into contact with the
wl_buffers produced by EGL. They are utterly opaque, and hidden inside
the EGL implementation. This means that, in order to get
colour-correct rendering through EGL, you either have to have it
attached to the surface (which the client can see and control), or you
have to grow EGL API for the entire breadth of colour management. This
is a lot of the reason why we have things like opaque region attached
to the surface, with the commit latched, rather than buffers.
Cheers,
Daniel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Chris Murphy
2016-12-21 19:24:33 UTC
Permalink
So...

Do applications (wayland clients) choose what compositor to use? Each
application could be using a different compositor?

Does it make any sense that there'd be three different classes of
compositor: no-color management, assume sRGB color management, and
full color management (all objects are explicitly tagged and the
compositor is doing display compensation with the help of e.g. lcms)?
Or am I missing something about compositors?


Chris Murphy
Carsten Haitzler (The Rasterman)
2016-12-22 06:20:21 UTC
Permalink
Post by Chris Murphy
So...
Do applications (wayland clients) choose what compositor to use? Each
application could be using a different compositor?
Does it make any sense that there'd be three different classes of
compositor: no-color management, assume sRGB color management, and
full color management (all objects are explicitly tagged and the
compositor is doing display compensation with the help of e.g. lcms)?
Or am I missing something about compositors?
your choice of wm or desktop chooses your compositor. choose gnome? it'll be
mutter. choose enlightenment? it'll be enlightenment. choose kde? it'll be
kwin etc. etc. etc.
Aha OK. And how does Weston fit into it? Do any of them directly
leverage Weston or is it just a reference to get Wayland support
included?
it's the reference/test compositor. if you want a fully working desktop these
days it's gnome's mutter, enlightenment or more recently kde's kwin has been
catching up. there is a tiling wm called sway as well. that's the major
compositors that are actually meant for "every day" use. weston isn't something
i'd say is useful for day to day (not without a lot of extending/work).
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Daniel Stone
2016-12-21 10:05:59 UTC
Permalink
Hi Graeme,
However, another
client could then come along and force your client off the plane, such
that you land in the compositor's GPU pipeline before display: this
rendering may be done in a 'lowest common denominator' colourspace,
such that the most optimal / least lossy output from your colour-aware
client would then _not_ correspond to your display device's native
characteristics.
Some details make for possible disadvantages with color
critical applications. Is a "lowest common denominator" space
one with a gamut smaller than any attached display, ensuring
that every color can be displayed without loss, while not
allowing any use of a displays full gamut, or is it
a colorspace that has a larger gamut than any attached
display, meaning that colors will get clipped in
ways the application has no control over, or may
not want ? (i.e. the particular application may
want some other intent such as perceptual or saturation
gamut mapping).
I mean lowest common denominator _between clients_, whilst still being
tied to the output. So the gamut would ideally be as wide as (the
specific output + highest gamut buffer being painted during this
stage), but in taking multiple clients with potentially disparate
colour source attributes and producing a single flat buffer, you may
need to unpick some properties of the client's colour attributes.

This is quite a big difference from X11, in that there is no longer a
giant single buffer for all displays. One of the benefits of the
aggressive decoupling we've done ...

Cheers,
Daniel
Graeme Gill
2017-01-05 01:43:08 UTC
Permalink
Daniel Stone wrote:

Hi,
Post by Daniel Stone
I mean lowest common denominator _between clients_, whilst still being
tied to the output. So the gamut would ideally be as wide as (the
specific output + highest gamut buffer being painted during this
stage), but in taking multiple clients with potentially disparate
colour source attributes and producing a single flat buffer, you may
need to unpick some properties of the client's colour attributes.
My apologies Daniel, I know I'm not following you, but I'll
blunder through a reply anyway, in the hope of stumbling on
some common ground:

I don't think there are any serious issues with rendering for
a single output from multiple source colorspaces within
an application, since the output has a single gamut that can be known.

But given that a surface can span more than one output, there is
no single color space that can simultaneously encompass all outputs
(disparate) gamuts, and yet clip in an application/user preferred
manner. I'm sure that the only way this is doable is for
the application to be able to specify in some non-intent-limited
way a transformation between each source colorspace and each particular
output space. (I say this after many years pondering the ICC's
attempt to decouple source and destination gamuts via the PCS
(Profile Connection Space), even though this is logically impossible.)
Post by Daniel Stone
This is quite a big difference from X11, in that there is no longer a
giant single buffer for all displays. One of the benefits of the
aggressive decoupling we've done ...
I'm not sure of the relevance. Nothing about application
color management cares about those sort of details. The
primary task is almost always transforming between two
specific device dependent colorspaces. Where the pixels
reside or what the buffers are shared with, or
how the pixels get spatially transformed is mostly irrelevant.
The device colorspaces that the buffers value represent is what's
important from a color management perspective.

Regards,
Graeme Gill.

Kai-Uwe
2016-12-20 14:46:11 UTC
Permalink
Post by Daniel Stone
On 19 November 2016 at 16:29, Niels Ole Salscheider
Post by Niels Ole Salscheider
+ <request name="colorspace_from_fd">
+ <description summary="creates a color space from an ICC profile">
+ This request allows to create a zwp_colorspace_v1 object from an ICC
+ profile. The fd argument is the file descriptor to the ICC profile (ICC
+ V2 or V4).
+ </description>
+ <arg name="fd" type="fd" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
This should probably take length + offset, and note explicitly whether
it requires NULL termination or not, and how that relates to the size.
Our experience with xkbcommon was that _not_ NULL-terminating was
ideal.
Color spaces are binaries. So NULL-termination might not apply?
Post by Daniel Stone
Post by Niels Ole Salscheider
+ <request name="blending_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_v1 object for the blending color
+ space of the compositor. All surfaces are converted by the compositor
+ to the blending color space before the blending operations. Once the
+ blending is performed, a further color conversion to the output color
+ spaces is carried out by the compositor.
+ A client should render in the blending color space returned by this
+ request if it does any color conversion on its own. This allows the
+ compositor to skip the color conversion to the blending color space.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
This might be a stupid question, but is the blending colourspace
constant, or could it feasibly be changed if you had, e.g., outputs
with different characteristics? I understand that blending in linear
space is a must, but are there other considerations in play which
could suggest multiple 'blending spaces' for a single compositor? (I
would expect that if the blending space was to be constant across
outputs, then it should also be statically derivable by clients,
making this event redundant.)
PDF, SVG2 require handling of different blending color spaces. So the
interface appears to be useful.
Post by Daniel Stone
Post by Niels Ole Salscheider
+ <request name="output_colorspace">
+ <description summary="returns the color space for the requested output">
+ This request returns a zwp_colorspace_v1 object for the requested
+ output. A client can use this when it does not want its surfaces to be
+ color-corrected. In this case it can attach the color space of its main
+ output to its surfaces.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
If a client doesn't want its surfaces to be colour-corrected ... won't
the compositor still convert into blending space and back (not
necessarily a lossless operation), if blending is required?
Likely.

My concern is that input == output color space => NULL conversion is
flacky. A explicite opt out of color correction would be much appreciated.

Kai-Uwe
Graeme Gill
2016-12-21 01:20:09 UTC
Permalink
Post by Kai-Uwe
PDF, SVG2 require handling of different blending color spaces. So the
interface appears to be useful.
Yes, but would the compositor really be used to implement this ?

My assumption is that blending is a facility to allow the
window manager to create various visual effects, such as
transparency between different application windows.
I also assume that if a window is configured to
be partially transparent, then all bets are off
as far as color accuracy for that window. Of course
it would be nice if color is minimally affected by
transparency.
Post by Kai-Uwe
My concern is that input == output color space => NULL conversion is
flacky. A explicite opt out of color correction would be much appreciated.
Setting a null (source) colorspace (is presumably) a way to do that, but
there is no mechanism for the application to know which
display the pixels will end up on, and objections have
been raised to providing the application with this information.

Graeme Gill.
Graeme Gill
2016-12-21 01:31:38 UTC
Permalink
Daniel Stone wrote:

Hi,
If there was a per-output blending colourspace (as well as final
display colourspace), that would make a great deal more sense to me.
Agreed. It depends on what is demanded of this blending colorspace -
if the demands are not highly critical, then either blending in
the native output space (fast and dirty), or blending in
a per-channel linear light output space at higher precision (say
16 bit or half) would result in linear light blending without
having any impact on color gamut or color precision for each output.

Graeme Gill.
Kai-Uwe
2016-12-20 19:38:05 UTC
Permalink
Hello Daniel,
Post by Kai-Uwe
Post by Daniel Stone
On 19 November 2016 at 16:29, Niels Ole Salscheider
Post by Niels Ole Salscheider
+ <request name="blending_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_v1 object for the blending color
+ space of the compositor. All surfaces are converted by the compositor
+ to the blending color space before the blending operations. Once the
+ blending is performed, a further color conversion to the output color
+ spaces is carried out by the compositor.
+ A client should render in the blending color space returned by this
+ request if it does any color conversion on its own. This allows the
+ compositor to skip the color conversion to the blending color space.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
This might be a stupid question, but is the blending colourspace
constant, or could it feasibly be changed if you had, e.g., outputs
with different characteristics? I understand that blending in linear
space is a must, but are there other considerations in play which
could suggest multiple 'blending spaces' for a single compositor? (I
would expect that if the blending space was to be constant across
outputs, then it should also be statically derivable by clients,
making this event redundant.)
PDF, SVG2 require handling of different blending color spaces. So the
interface appears to be useful.
I'm not quite sure how this response relates to my question, unless
you are discussing a Weston compositor which targets PDF and/or SVG.
I am talking about source documents, which might be PDF or SVG. And in
these the blending space can change. So a Wayland client might draw each
PDF/SVG element to a Wayland surface and would come in need to switch
the blending space for rendering the document. Doing it all in Wayland
makes the server much more powerful.
In Niels's strawman proposal, there is only _one_ blending colourspace
for _every_ blending operation performed in the _entire_ compositor.
Ah ok. So take my comment as the hint for a possible use case for
multiple blending spaces ;-)
Post by Kai-Uwe
Post by Daniel Stone
Post by Niels Ole Salscheider
+ <request name="output_colorspace">
+ <description summary="returns the color space for the requested output">
+ This request returns a zwp_colorspace_v1 object for the requested
+ output. A client can use this when it does not want its surfaces to be
+ color-corrected. In this case it can attach the color space of its main
+ output to its surfaces.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
If a client doesn't want its surfaces to be colour-corrected ... won't
the compositor still convert into blending space and back (not
necessarily a lossless operation), if blending is required?
Likely.
My concern is that input == output color space => NULL conversion is
flacky. A explicite opt out of color correction would be much appreciated.
What does an explicit opt-out actually mean? Does it mean that the
compositor assumes sRGB? Linear? That a NULL transform is applied when
scanning out directly from that surface? When going through a GPU
composition pipeline, is the inverse transform from the output
colourspace to blending colourspace, or does 'opt out' mean that
blending is performed directly in the target colourspace?
From the main use case of drawing channel values unaltered to the
output, I would say the later. That is as well the current behavior,
without any color correction and changed happening only while blending.
There is no gamma conversion, no color space conversion. The conflict
might be that blending ops work currently best for gamma encoded values
and might be changed to work for linear gamma 1.0 . The transition from
a gamma image to convert to linear gamma for blending should not be
noticeable, perhaps measurable. Further there is the need to copy the
surface for blending to linear gamma. For this case, do not touch the
values, it appears appropriate.
I'm also curious as to what you mean by it being flaky.
Flaky - the client cant not know what happens to its values as
output==output => NULL is a implicit rule. It might be optimised out or
whatever at will of the server and the client is a real looser as it is
only a weak suggestion. A Do Not Touch (or opt out) marker is pretty
clear to everyone and the client can assume to remain in control like
with a contract.

Kai-Uwe
Daniel Stone
2016-12-21 09:50:44 UTC
Permalink
Hi Kai-Uwe,
Post by Kai-Uwe
Post by Kai-Uwe
PDF, SVG2 require handling of different blending color spaces. So the
interface appears to be useful.
I'm not quite sure how this response relates to my question, unless
you are discussing a Weston compositor which targets PDF and/or SVG.
I am talking about source documents, which might be PDF or SVG. And in
these the blending space can change. So a Wayland client might draw each
PDF/SVG element to a Wayland surface and would come in need to switch
the blending space for rendering the document. Doing it all in Wayland
makes the server much more powerful.
In Niels's strawman proposal, there is only _one_ blending colourspace
for _every_ blending operation performed in the _entire_ compositor.
Ah ok. So take my comment as the hint for a possible use case for
multiple blending spaces ;-)
Yes, if you look at the request as written, it's about _retrieving_
the compositor's single blending space, not setting one. I don't think
that's adequate, and as you say, it may be a good solution for clients
to provide profiles enabling the compositor to transform for both
final display and for blending.
Post by Kai-Uwe
Post by Kai-Uwe
My concern is that input == output color space => NULL conversion is
flacky. A explicite opt out of color correction would be much appreciated.
What does an explicit opt-out actually mean? Does it mean that the
compositor assumes sRGB? Linear? That a NULL transform is applied when
scanning out directly from that surface? When going through a GPU
composition pipeline, is the inverse transform from the output
colourspace to blending colourspace, or does 'opt out' mean that
blending is performed directly in the target colourspace?
From the main use case of drawing channel values unaltered to the
output, I would say the later. That is as well the current behavior,
without any color correction and changed happening only while blending.
There is no gamma conversion, no color space conversion. The conflict
might be that blending ops work currently best for gamma encoded values
and might be changed to work for linear gamma 1.0 . The transition from
a gamma image to convert to linear gamma for blending should not be
noticeable, perhaps measurable. Further there is the need to copy the
surface for blending to linear gamma. For this case, do not touch the
values, it appears appropriate.
But that means that blending (in non-linear space) will look pretty awful. :\
Post by Kai-Uwe
I'm also curious as to what you mean by it being flaky.
Flaky - the client cant not know what happens to its values as
output==output => NULL is a implicit rule. It might be optimised out or
whatever at will of the server and the client is a real looser as it is
only a weak suggestion. A Do Not Touch (or opt out) marker is pretty
clear to everyone and the client can assume to remain in control like
with a contract.
It can assume, but it really shouldn't. The client can make its
guesses and assumptions about what's going on, but the compositor is
free to do much more than what it was under X11, and what it can
express to the client. Given the diversity of what compositors do:
blending, surface transformation/displacement and cloning across
multiple outputs, cloned outputs, screenshots/streaming, etc, this
will always be a guess. And this makes me wince every time I see 'opt
out'; the intention when writing it is 'the client knows what's going
on so can get it right', but I read 'the client doesn't know what the
compositor's doing and the compositor doesn't know what the client
means, which guarantees that it's going to get it wrong at some
point'.

I'm still missing some subtlety in your point, but perhaps there's
language you could suggest for some part of Niels's strawman spec,
which would strengthen these guarantees to a point a client could be
assured the right thing was happening. I don't see any future for an
'opt out' flag ever though.

Cheers,
Daniel
Niels Ole Salscheider
2016-12-27 13:27:16 UTC
Permalink
Hi Niels,
Just nitpicking at the protocol side of things a little bit; please
excuse what I'm sure is a horrific abuse of the terminology, contained
in what I'm sure is a series of stupid questions.
On 19 November 2016 at 16:29, Niels Ole Salscheider
Post by Niels Ole Salscheider
+ <interface name="zwp_color_management_v1" version="1">
+ <description summary="allows attaching a color space to a wl_surface">
+ This interface allows attaching a color space to a wl_surface. The
+ compositor uses this information to display the colors correctly.
+ For this, the compositor converts any attached surfaces to the
blending + color space before performing the blending operations.
After blending, + the output surface is converted to the color space
of the output device. + This interface also provides requests for
the sRGB and the blending color + space. It further allows creation
of a color space from an ICC profile. + The client is informed by an
event if the color space of one of the + outputs changes.
+ </description>
+
+ <request name="set_colorspace">
+ <description summary="set the color space of a wl_surface">
+ With this request, the color space of a wl_surface can be set.
+ The sRGB colorspace is attached to a surface before
set_colorspace is + called for the first time.
+ </description>
+ <arg name="surface" type="object" interface="wl_surface" />
+ <arg name="colorspace" type="object" interface="zwp_colorspace_v1"
/> + </request>
Hm. When does this apply: is it at the next wl_surface::commit, or
immediately? FWIW, the correct answer for this is the former. ;)
Yes, the former is right. I will make this more explicit.
Putting explicit language in to this effect would be good; it may also
be nice to have this new_id a separate per-surface object, so the
application can then destroy the object to opt out, e.g. if it starts
embedding content of an unknown colourspace, so the best option is to
have the compositor convert from sRGB.
Can you explain what exactly you mean by per-surface objects? Do you suggest
to add a wl_surface argument to the zwp_colorspace_v1 object or how would it
work?

The reason why I did not do this was because I expect that many (sub)surfaces
will use the same color profile, e. g. sRGB or the preferred (blending) color
space of the compositor.
We can avoid the former by defining that no colorspace object implies sRGB.
But that does not help for the preferred color space that might be used if the
client does simple color conversions on its own.
Another good reason to have a per-surface object is so you have
explicit control: only one per-surface object can be active at any
time, and that surface is free to call set_colorspace as many times as
it wants. Without per-surface objects, you can't enforce the same
'only one at a time' model.
My idea was that set_colorspace can be called as often as the client wants -
the new color profile will be used once wl_surface.commit is called and the
old profile won't have effect anymore from there on.
Post by Niels Ole Salscheider
+ <request name="colorspace_from_fd">
+ <description summary="creates a color space from an ICC profile">
+ This request allows to create a zwp_colorspace_v1 object from an
ICC + profile. The fd argument is the file descriptor to the ICC
profile (ICC + V2 or V4).
+ </description>
+ <arg name="fd" type="fd" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
This should probably take length + offset, and note explicitly whether
it requires NULL termination or not, and how that relates to the size.
Our experience with xkbcommon was that _not_ NULL-terminating was
ideal.
I have never seen length and offset arguments in other wayland requests that
take an fd (do you have an example?). But I can add it if it is useful.
Post by Niels Ole Salscheider
+ <request name="srgb_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_1 object for the sRGB color
+ space. The sRGB color space is initially attached to all surfaces.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
Why is returning this object useful? The only use I can see is to
return the surface to the 'unset' state, which could possibly be more
cleanly handled by destroying a per-surface object. The description is
also copypasta.
Yes, the use case is to reset the color profile to sRGB. If we switch to per-
surface objects we can remove this.
Post by Niels Ole Salscheider
+ <request name="blending_colorspace">
+ <description summary="tell the client what blending space is used">
+ This request returns a zwp_colorspace_v1 object for the blending
color + space of the compositor. All surfaces are converted by the
compositor + to the blending color space before the blending
operations. Once the + blending is performed, a further color
conversion to the output color + spaces is carried out by the
compositor.
+ A client should render in the blending color space returned by
this + request if it does any color conversion on its own. This
allows the + compositor to skip the color conversion to the
blending color space. + </description>
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
This might be a stupid question, but is the blending colourspace
constant, or could it feasibly be changed if you had, e.g., outputs
with different characteristics? I understand that blending in linear
space is a must, but are there other considerations in play which
could suggest multiple 'blending spaces' for a single compositor? (I
would expect that if the blending space was to be constant across
outputs, then it should also be statically derivable by clients,
making this event redundant.)
I really intended this to return the preferred input color space of the
compositor and not necessarily a blending space. I have reworded this.

I could imagine that the preferred input color space might depend on the
output on which the surface is displayed. But in this case we need a per-
surface preferred color space and an event that notifies the client when this
changes (e. g. because the surface is displayed on a different output). Such a
change means that the client has to set up new cLUTs and so on if it does
color conversions on its own.

I'm not sure if it is worth the effort and added complexity or if we should
just stick with a static preferred input color space.
Post by Niels Ole Salscheider
+ <request name="output_colorspace">
+ <description summary="returns the color space for the requested
output"> + This request returns a zwp_colorspace_v1 object for the
requested + output. A client can use this when it does not want
its surfaces to be + color-corrected. In this case it can attach
the color space of its main + output to its surfaces.
+ </description>
+ <arg name="output" type="object" interface="wl_output" />
+ <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
+ </request>
If a client doesn't want its surfaces to be colour-corrected ... won't
the compositor still convert into blending space and back (not
necessarily a lossless operation), if blending is required?
My next RFC will avoid this problem with device link profiles.
Post by Niels Ole Salscheider
+ <event name="output_colorspace_changed">
+ <description summary="tell the client what color space an output
has"> + This event will be sent when the color space of an output
is changed. + </description>
+ <arg name="output" type="object" interface="wl_output" />
+ </event>
These three, linked together, are somewhat awkward, but then again, so
are server-created objects.
Post by Niels Ole Salscheider
+ <interface name="zwp_colorspace_v1" version="1">
+ <description summary="represents a color space">
+ This interface represents a color space that can be attached to
surfaces. + It is used by the zwp_color_management_v1 interface.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroys the zwp_colorspace_v1 object">
+ Informs the server that the client will not be using this protocol
+ object anymore.
+ </description>
+ </request>
What happens when destroying a colorspace object which is still
attached to a surface?
This should probably not be allowed or we define that it falls back to sRGB.
Post by Niels Ole Salscheider
+ <request name="get_profile_fd">
+ <description summary="get a file descriptor to the profile data">
+ This request will cause a profile_fd event that returns a file
+ descriptor to the ICC profile data of this colorspace.
+ </description>
+ </request>
+
+ <event name="profile_data">
+ <description summary="file descriptor to the profile data">
+ This event occurs after a get_profile_fd request and returns the
file + descriptor to the ICC profile data of this colorspace.
+ </description>
+ <arg name="fd" type="fd" />
+ </event>
This also needs length + offset, no?
Cheers,
Daniel
Daniel Stone
2016-12-02 12:30:53 UTC
Permalink
Hi Nils,

On 19 November 2016 at 16:29, Niels Ole Salscheider
Post by Niels Ole Salscheider
it has been some time since I proposed the first two RFCs for a color
https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html
During the discussion of the second RFC it became clear that color correction
was out of scope for weston at that time.
In the meantime wayland-protocols was split from weston and libweston was
created. Several wayland compositors start to see everyday usage and wide-gamut
screens became more common so that color management becomes more important.
Therefore I think that the situation has changed and I'd like to propose this
protocol for inclusion in wayland-protocols again.
What do you think?
Yes, I think you're right, and it's time to start looking at it again.
Now Weston is a bit more mature/capable, the desktop environments have
caught up and are at the point where it makes sense for them to look
at it, and we have wayland-protocols rather than the old
weston/protocols/ dumping ground, it's probably the right time.

Cheers,
Daniel
Carsten Haitzler (The Rasterman)
2016-12-08 06:12:47 UTC
Permalink
Post by Daniel Stone
Hi Nils,
On 19 November 2016 at 16:29, Niels Ole Salscheider
Post by Niels Ole Salscheider
it has been some time since I proposed the first two RFCs for a color
https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html
During the discussion of the second RFC it became clear that color
correction was out of scope for weston at that time.
In the meantime wayland-protocols was split from weston and libweston was
created. Several wayland compositors start to see everyday usage and
wide-gamut screens became more common so that color management becomes more
important.
Therefore I think that the situation has changed and I'd like to propose
this protocol for inclusion in wayland-protocols again.
What do you think?
Yes, I think you're right, and it's time to start looking at it again.
Now Weston is a bit more mature/capable, the desktop environments have
caught up and are at the point where it makes sense for them to look
at it, and we have wayland-protocols rather than the old
weston/protocols/ dumping ground, it's probably the right time.
i'm curious... is the intent to make it requird that all compositors support
color management (and thus have to support all the possible colorspaces
defined)... or are we going to go the path of:

99% of apps won't care so color correction is an optional extra and apps need
to query for the support then adapt appropriately (and always fall back to SRGB
as is defined as the default if it's not supported)?

what is the path/intent for this?
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-08 06:32:37 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
i'm curious... is the intent to make it requird that all compositors support
color management (and thus have to support all the possible colorspaces
I'd be happy if there was support for core color management (i.e. application
color management), before adding layers that depend on the core.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-09 03:02:07 UTC
Permalink
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
i'm curious... is the intent to make it requird that all compositors support
color management (and thus have to support all the possible colorspaces
I'd be happy if there was support for core color management (i.e. application
color management), before adding layers that depend on the core.
but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client? or will it be expected that apps need to
always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-09 04:30:40 UTC
Permalink
Carsten Haitzler (The Rasterman) wrote:

Hi,
Post by Carsten Haitzler (The Rasterman)
but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client?
My intent is directly the opposite.

An application could choose to fail if core color management is not
present, or fall back into a non-color managed mode. An application
that wants to use Enhance color management and finds it is not present,
could fall back to application color management (although it probably
wouldn't, because it doesn't want to work that hard), or fall back
into a non-color managed mode.
Post by Carsten Haitzler (The Rasterman)
or will it be expected that apps need to
always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?
I thought I'd explained this in the previous post ? - perhaps
I'm simply not understanding where you are coming from on this.

The intent is to enable proper color management. In general, only
the application will be able to do this to its own satisfaction,
so core color management is essential. Providing enhanced color
management is a convenience to applications that don't wish to
implement their own color management and are content with
quite limited set of capabilities, as well as making available
a facility to force default color management onto applications
that are not color aware.

If this doesn't make sense to you, then perhaps the best thing
would be for me to lay out the nuts and bolts of what's happening
in these different color management scenarios.

Cheers,

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-10 02:21:48 UTC
Permalink
Post by Graeme Gill
Hi,
Post by Carsten Haitzler (The Rasterman)
but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client?
My intent is directly the opposite.
An application could choose to fail if core color management is not
present, or fall back into a non-color managed mode. An application
that wants to use Enhance color management and finds it is not present,
could fall back to application color management (although it probably
wouldn't, because it doesn't want to work that hard), or fall back
into a non-color managed mode.
Post by Carsten Haitzler (The Rasterman)
or will it be expected that apps need to
always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?
I thought I'd explained this in the previous post ? - perhaps
I'm simply not understanding where you are coming from on this.
you didn't explain before if the point is for this to be mandatory or optional.

above you basically say it has to be mandatory as applications will then fail
to run (at least some set of them might).

when you add extra features like new colorspace support, people writing apps
and toolkits nee to know what the expectation is. can they just assume it will
work, or do they need to have a fallback path on their side.

compositor writers need to know too. if color management is mandatory then
their compositor is basically broken until they add it.
Post by Graeme Gill
The intent is to enable proper color management. In general, only
the application will be able to do this to its own satisfaction,
so core color management is essential. Providing enhanced color
management is a convenience to applications that don't wish to
implement their own color management and are content with
quite limited set of capabilities, as well as making available
a facility to force default color management onto applications
that are not color aware.
i don't see a difference between enhanced and core. color management means:

1. being able to report what colorspace is "default" on the display right now
(and what may be able to be enabled possible at request).
2. being able to report what colorspaces are supported at all (either natively
by the display or by emulation)
3. the ability for a client to define a specific colorspace for a buffer. (the
choice of the colorspace of the display itself should be left to the
compositor).

the only difference is the set of colorspaces wanted by client and by supported
by compositor. core and enhanced are arbitrary labels. what matters is a
common colorspace. right now in wayland it's all sRGB so everyone agrees (i'm
ignoring yuv etc. buffer formats. just talking RGB ones).

so the questions are:

* if all of these above are missing: what happens?
* if the list of colorspaces natively supported by the screen does not have a
common set of colorspaces the client wants: what happens?
* if the list of all colorspaces (native or emulated) by the compositor does
not have a common set with the client: what happens?

should a client fall back to sRGB is that the intent and otherwise get enhanced
display if color management is there? should a client just give up and exit or
display nothing?

you say the latter. a client can choose to fail entirely, which imho leads to a
far poorer outcome for the user. the vast majority of users out there in the
world have a non-calibrated dumb monitor or maybe don't even have a choice
in screen since it's built in (tablet, phone, laptop, watch ... fridge) and
that's all they will ever have. if this is just intended for enhanced support
then i think this is good.
Post by Graeme Gill
If this doesn't make sense to you, then perhaps the best thing
would be for me to lay out the nuts and bolts of what's happening
in these different color management scenarios.
what i want to know if how mandatory will this be, as most users will never
have a scenario where their display can do more than "dumb" sRGB and any
compositor claiming to support colorspaces will have to convert down to sRGB
anyway, and if clients start exiting because the compositor is being honest and
saying that that colorspace cant be supported, then this will eventually lead
to compositors lying and claiming all these colorspaces work/are native to stop
apps exiting, and so now all you do is add overhead to work around client apps
that are just behaving badly.

if this is mandatory as you say, then i dislike this protocol very much. if
it's optional then i think it's good.
Post by Graeme Gill
Cheers,
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-13 06:14:21 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
I thought I'd explained this in the previous post ? - perhaps
I'm simply not understanding where you are coming from on this.
you didn't explain before if the point is for this to be mandatory or optional.
I'm not sure exactly what you mean by "this".

I've suggested two color management extensions, one building on
the other. By being an extension, I assume that neither one is
mandatory, although "core" would be a dependence of "enhanced".
Post by Carsten Haitzler (The Rasterman)
above you basically say it has to be mandatory as applications will then fail
to run (at least some set of them might).
That's not at all what I said. I said that applications have the
option of falling back to more basic approaches :-
enhance back to core, core back to none.
Post by Carsten Haitzler (The Rasterman)
when you add extra features like new colorspace support, people writing apps
and toolkits nee to know what the expectation is. can they just assume it will
work, or do they need to have a fallback path on their side.
I've not mentioned any new colorspace support, so I'm not
sure what you are talking about.
Post by Carsten Haitzler (The Rasterman)
compositor writers need to know too. if color management is mandatory then
their compositor is basically broken until they add it.
Naturally a compositor that supports an extension, would
would have to implement it!
Post by Carsten Haitzler (The Rasterman)
i don't see a difference between enhanced and core.
Hmm. They are quite distinct.

core: The application either implements its own CMM (lcms or
ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
(i.e. ColorSync, WCS, AdobeCMM etc.).

enchanced: The compositor implements some level of CMM itself,
using one of the above libraries, GPU etc.

core: The application requires information from the graphics
system (via Wayland in this particular discussion), namely
the profile for the display corresponding to each
pixel region.

enhanced: The compositor is provided with source colorspace
profiles by the application.

core: The application uses its CMM to transform source colorspaces
to the display colorspaces, and sends the pixels to the graphics system.

enhanced: The compositor uses its CMM to transform the pixels provided
by the application in the provided source colorspaces to the display
colorspaces.
Post by Carsten Haitzler (The Rasterman)
1. being able to report what colorspace is "default" on the display right now
(and what may be able to be enabled possible at request).
I'm not sure what you mean by "enabled". A display colorspaces is just information
that is needed by the CMM, so it is either known and available to what needs
it, or not known or not available to what needs it.
Post by Carsten Haitzler (The Rasterman)
2. being able to report what colorspaces are supported at all (either natively
by the display or by emulation)
Not needed for core color management - all that is required is
to be able to send pixels in the native display space to the display.
Post by Carsten Haitzler (The Rasterman)
3. the ability for a client to define a specific colorspace for a buffer. (the
choice of the colorspace of the display itself should be left to the
compositor).
Not needed for core color management - the application deals
with source color spaces internally.

To reiterate:

1) Core color management support is essential because you can't assume that
a CMM implemented in the compostor has all the capabilities that every
application requires - particularly if it is a color critical application.

2) Core color management support is essential to allow color management applications
such as color profilers work. Without color profilers, there are no accurate
color profiles for your display, and color critical applications won't be viable.

If you want Wayland to be on parity with existing systems (MSWin, OS X, X11),
then you need core color management support.
Post by Carsten Haitzler (The Rasterman)
the only difference is the set of colorspaces wanted by client and by supported
by compositor. core and enhanced are arbitrary labels.
No. See above.
Post by Carsten Haitzler (The Rasterman)
what matters is a
common colorspace. right now in wayland it's all sRGB so everyone agrees (i'm
ignoring yuv etc. buffer formats. just talking RGB ones).
That's not how CMM's work. The common color space is the profile connection
space, which is based on CIE XYZ.
Post by Carsten Haitzler (The Rasterman)
* if all of these above are missing: what happens?
* if the list of colorspaces natively supported by the screen does not have a
common set of colorspaces the client wants: what happens?
* if the list of all colorspaces (native or emulated) by the compositor does
not have a common set with the client: what happens?
Only questions for enhanced color management, and since this isn't
required by color critical applications, a relaxed level of support
is likely to be useful.
Post by Carsten Haitzler (The Rasterman)
what i want to know if how mandatory will this be, as most users will never
have a scenario where their display can do more than "dumb" sRGB and any
compositor claiming to support colorspaces will have to convert down to sRGB
anyway, and if clients start exiting because the compositor is being honest and
saying that that colorspace cant be supported, then this will eventually lead
to compositors lying and claiming all these colorspaces work/are native to stop
apps exiting, and so now all you do is add overhead to work around client apps
that are just behaving badly.
These sorts of issues only arise if your be-all and end-all of color management
is doing it in the compositor, and for the reasons I state above, I don't
think this is satisfactory.

If color management is an extension, I don't see how any of it can be mandatory.

Naturally in a color managed situation there are a variety of options for
providing fall back display color profiles - for instance: display type generic,
EDID derived profiles, or worst case assume sRGB.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-14 06:58:33 UTC
Permalink
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
I thought I'd explained this in the previous post ? - perhaps
I'm simply not understanding where you are coming from on this.
you didn't explain before if the point is for this to be mandatory or optional.
I'm not sure exactly what you mean by "this".
this == support for color correction protocol AND actually the support for
providing the real colorspace of the monitor, providing non SRGB pixel data by
clients in another colorspace (eg adobe) and it MUST work or apps will
literally fall over.

at the end of the day there will be some extension and then some form of
guidance to developers. e.g. you can guarantee this will work, or "this may or
may not work. deal with it".
Post by Graeme Gill
I've suggested two color management extensions, one building on
the other. By being an extension, I assume that neither one is
mandatory, although "core" would be a dependence of "enhanced".
well there are extensions that are managed outside of wayland as a project.
these obviously are not mandatory. the more core it becomes the more it is
likely "mandatory".
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
above you basically say it has to be mandatory as applications will then
fail to run (at least some set of them might).
That's not at all what I said. I said that applications have the
option of falling back to more basic approaches :-
enhance back to core, core back to none.
yes. my bad. i misread the replies and quotes. i thought you said "not at all"
to the "clients should fall back" path.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
when you add extra features like new colorspace support, people writing apps
and toolkits nee to know what the expectation is. can they just assume it
will work, or do they need to have a fallback path on their side.
I've not mentioned any new colorspace support, so I'm not
sure what you are talking about.
not a format. a colorspce. R numbers are still R, as are G and B. it's just
that they point to different "real life spectrum" colors and so they need to be
transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
compositor writers need to know too. if color management is mandatory then
their compositor is basically broken until they add it.
Naturally a compositor that supports an extension, would
would have to implement it!
Post by Carsten Haitzler (The Rasterman)
i don't see a difference between enhanced and core.
Hmm. They are quite distinct.
core: The application either implements its own CMM (lcms or
ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
(i.e. ColorSync, WCS, AdobeCMM etc.).
enchanced: The compositor implements some level of CMM itself,
using one of the above libraries, GPU etc.
core: The application requires information from the graphics
system (via Wayland in this particular discussion), namely
the profile for the display corresponding to each
pixel region.
i really do not think this is needed. simply a list of available colorspaces
would be sufficient. application then provide data in the colorspace of it's
choice given what is supported by the compositor and the input data it has...
Post by Graeme Gill
enhanced: The compositor is provided with source colorspace
profiles by the application.
i again don't see why this is needed.
Post by Graeme Gill
core: The application uses its CMM to transform source colorspaces
to the display colorspaces, and sends the pixels to the graphics system.
enhanced: The compositor uses its CMM to transform the pixels provided
by the application in the provided source colorspaces to the display
colorspaces.
again - we're just arguing who does the transform. i don't see the point. the
compositor will have a list of colorspaces it can display (either A screen can
display this OR can be configured to display in this colorspace, ... OR the
compositor can software transform pixels in this colorspace to whatever is
necessary to display correctly).

the client simply chooses what colorspace to provide buffers in. it chooses the
one that is best for it.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
1. being able to report what colorspace is "default" on the display right
now (and what may be able to be enabled possible at request).
I'm not sure what you mean by "enabled". A display colorspaces is just
information that is needed by the CMM, so it is either known and available to
what needs it, or not known or not available to what needs it.
a colorspace that is enabled is when the display output for that screen maps
RGB values directly to that given colorspace. i.e. the common default is sRGB.
the display may be also able to switch to adobe rgb at the flip of a switch or
by request from the host system (via data lines). it may be fixed and only one
colorspace is every able to be displayed.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
2. being able to report what colorspaces are supported at all (either
natively by the display or by emulation)
Not needed for core color management - all that is required is
to be able to send pixels in the native display space to the display.
then it's a list of 1 colorspace: "sRGB" :) wehich is the current default/state
of play in wayland anyway.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
3. the ability for a client to define a specific colorspace for a buffer.
(the choice of the colorspace of the display itself should be left to the
compositor).
Not needed for core color management - the application deals
with source color spaces internally.
then you need no colormanagement at all. just assume sRGB (gamma2.2 or
whatever). zero colormanagement protocol or support needed. totally up to
client. the compositor MIGHT know its colorspace/profile and report it here
without sRGB listed then. thats how you know you only have 1 colorspace.
Post by Graeme Gill
1) Core color management support is essential because you can't assume that
a CMM implemented in the compostor has all the capabilities that every
application requires - particularly if it is a color critical application.
thus why i asked if apps will be expected to be able to fallback and DIY
client-side (and present sRGB).
Post by Graeme Gill
2) Core color management support is essential to allow color management
applications such as color profilers work. Without color profilers, there are
no accurate color profiles for your display, and color critical applications
won't be viable.
If you want Wayland to be on parity with existing systems (MSWin, OS X, X11),
then you need core color management support.
how we're talking about color profiling tools that want to create a color
mapping/profile for that display so colors display correctly. you need a
colorimiter to measure output of course to do this.

this could be nothing more than a "1:1 do nothing" colorspace. that means R,G
and B values are transmitted with no changes. changing the content of your
buffer sends different signals that the colorimiter can read and thus be used
to create a color profile/mapping for your display.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
the only difference is the set of colorspaces wanted by client and by
supported by compositor. core and enhanced are arbitrary labels.
No. See above.
i don't get why you need so much complexity.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
what matters is a
common colorspace. right now in wayland it's all sRGB so everyone agrees
(i'm ignoring yuv etc. buffer formats. just talking RGB ones).
That's not how CMM's work. The common color space is the profile connection
space, which is based on CIE XYZ.
ummm i'm talking about the values of pixels. RGB. what physical color does
#ff0000 produce? #00ff00 or #0000ff or #880000 or #008800 etc. etc. - that is
what colormanagement is all about. it's about knowing the physical wavelengths
of light produced when those values are displayed by a screen and then
ADJUSTING the values provided in order to display the correct physical color.

do we agree or disagree?
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
* if all of these above are missing: what happens?
* if the list of colorspaces natively supported by the screen does not
have a common set of colorspaces the client wants: what happens?
* if the list of all colorspaces (native or emulated) by the compositor
does not have a common set with the client: what happens?
Only questions for enhanced color management, and since this isn't
required by color critical applications, a relaxed level of support
is likely to be useful.
a list of "just 1 colorspace" matches your core concept.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
what i want to know if how mandatory will this be, as most users will never
have a scenario where their display can do more than "dumb" sRGB and any
compositor claiming to support colorspaces will have to convert down to sRGB
anyway, and if clients start exiting because the compositor is being honest
and saying that that colorspace cant be supported, then this will
eventually lead to compositors lying and claiming all these colorspaces
work/are native to stop apps exiting, and so now all you do is add overhead
to work around client apps that are just behaving badly.
These sorts of issues only arise if your be-all and end-all of color
management is doing it in the compositor, and for the reasons I state above,
I don't think this is satisfactory.
the compositor MAY NOT transform. it doesnt have to. it can lie. as long as it
knows the colorspace/profile of the output and reports that as the one and ONLY
colorspace supported in the list, then you have what you want. right?
Post by Graeme Gill
If color management is an extension, I don't see how any of it can be mandatory.
extensions can be mandatory. if clients in the greater part cease to work at
all without the extension present and working in a specific way.
Post by Graeme Gill
Naturally in a color managed situation there are a variety of options for
providing fall back display color profiles - for instance: display type
generic, EDID derived profiles, or worst case assume sRGB.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-14 12:23:59 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
this == support for color correction protocol AND actually the support for
providing the real colorspace of the monitor, providing non SRGB pixel data by
clients in another colorspace (eg adobe) and it MUST work or apps will
literally fall over.
That's not a scheme I'm recommending.
Post by Carsten Haitzler (The Rasterman)
at the end of the day there will be some extension and then some form of
guidance to developers. e.g. you can guarantee this will work, or "this may or
may not work. deal with it".
Sure.
Post by Carsten Haitzler (The Rasterman)
well there are extensions that are managed outside of wayland as a project.
these obviously are not mandatory. the more core it becomes the more it is
likely "mandatory".
Sure.
Post by Carsten Haitzler (The Rasterman)
not a format. a colorspce. R numbers are still R, as are G and B. it's just
that they point to different "real life spectrum" colors and so they need to be
transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).
My point stands. I've not mentioned new colorspaces.
Post by Carsten Haitzler (The Rasterman)
i really do not think this is needed. simply a list of available colorspaces
would be sufficient. application then provide data in the colorspace of it's
choice given what is supported by the compositor and the input data it has...
And I think it is core, for all the reasons I've listed.
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
enhanced: The compositor is provided with source colorspace
profiles by the application.
i again don't see why this is needed.
Hmm. How else does the compositor know how to transform from
the given colorspace to the display colorspace ?
Post by Carsten Haitzler (The Rasterman)
again - we're just arguing who does the transform.
It's not "just", it's the point.
Post by Carsten Haitzler (The Rasterman)
i don't see the point. the
compositor will have a list of colorspaces it can display (either A screen can
display this OR can be configured to display in this colorspace, ... OR the
compositor can software transform pixels in this colorspace to whatever is
necessary to display correctly).
I don't know how many different ways I can explain the same thing. The compositor
can't know how to transform color in all the ways an application may need
to transform color. I think it is unlikely for instance, that you are
proposing that the compositor support full N-Color, device links, ICC-Max
support, etc., or the infinity of ways that haven't been invented yet to
transform between color spaces. So the core color management requirement
is that the application be able to transform into the device colorspace itself.
Post by Carsten Haitzler (The Rasterman)
the client simply chooses what colorspace to provide buffers in. it chooses the
one that is best for it.
A core requirement is that the client be able to know what output device
colorspace each pixel is destined for, and provide a buffer that the
compositor doesn't touch (i.e. it has no source colorspace label
other than don't touch these pixels").
Post by Carsten Haitzler (The Rasterman)
a colorspace that is enabled is when the display output for that screen maps
RGB values directly to that given colorspace. i.e. the common default is sRGB.
No. No color transformation by the compositor, so no colorspace.
Post by Carsten Haitzler (The Rasterman)
the display may be also able to switch to adobe rgb at the flip of a switch or
by request from the host system (via data lines). it may be fixed and only one
colorspace is every able to be displayed.
A color critical user won't put up with such things - they expect to
be in control over what's happening, and if a system has proper
color management (core + enhanced), there is absolutely no
reason for them to run the display in anything other than it's native gamut.
Post by Carsten Haitzler (The Rasterman)
then it's a list of 1 colorspace: "sRGB" :) wehich is the current default/state
of play in wayland anyway.
No, it's a list of N output display colorspaces, one for each display.
Post by Carsten Haitzler (The Rasterman)
then you need no colormanagement at all.
As explained, yes, core color management needs support -
control over VideoLUT state, plus registration of the output
display colorspaces + knowledge of which output the different
parts of a surface map to.
Post by Carsten Haitzler (The Rasterman)
just assume sRGB (gamma2.2 or
whatever). zero colormanagement protocol or support needed. totally up to
client. the compositor MIGHT know its colorspace/profile and report it here
without sRGB listed then. thats how you know you only have 1 colorspace.
I'm not sure _what_ you are talking about. sRGB doesn't come into it.
Post by Carsten Haitzler (The Rasterman)
thus why i asked if apps will be expected to be able to fallback and DIY
client-side (and present sRGB).
It's not a fallback, it's core (basic) color management.
Post by Carsten Haitzler (The Rasterman)
how we're talking about color profiling tools that want to create a color
mapping/profile for that display so colors display correctly. you need a
colorimiter to measure output of course to do this.
Yes, and ?
Post by Carsten Haitzler (The Rasterman)
this could be nothing more than a "1:1 do nothing" colorspace. that means R,G
and B values are transmitted with no changes. changing the content of your
buffer sends different signals that the colorimiter can read and thus be used
to create a color profile/mapping for your display.
Right - the sort of thing that is provided by a core/basic color
management support.
Post by Carsten Haitzler (The Rasterman)
i don't get why you need so much complexity.
It's the simplest possible support, (hence calling it "core").
It's needed internally anyway for a compositor to implement CMM
operations for "enhance" color management.
Post by Carsten Haitzler (The Rasterman)
ummm i'm talking about the values of pixels. RGB. what physical color does
#ff0000 produce? #00ff00 or #0000ff or #880000 or #008800 etc. etc. - that is
what colormanagement is all about.
No it's not. That's just one aspect of it. The main game is in
how one device colorspace is transformed into another.
Post by Carsten Haitzler (The Rasterman)
it's about knowing the physical wavelengths
of light produced when those values are displayed by a screen and then
ADJUSTING the values provided in order to display the correct physical color.
Hmm. Not really. Mostly a lot of other stuff has to go on top of that
to make things turn out how people expect (source colorspace definition,
white point mapping, gamut clipping or mapping, black point mapping etc.)
Post by Carsten Haitzler (The Rasterman)
a list of "just 1 colorspace" matches your core concept.
No. See above, and my original sketch.
Post by Carsten Haitzler (The Rasterman)
the compositor MAY NOT transform. it doesnt have to. it can lie. as long as it
knows the colorspace/profile of the output and reports that as the one and ONLY
colorspace supported in the list, then you have what you want. right?
It's a poor approach to rely on the "null transform" hack. It's clumsy,
doesn't convey the actual intent and expectation of operation, and leads
to complications. For instance:

* Null transform is a hack. Only under particular conditions
(matrix profile with equation defined per channel curves)
is a profile "exactly" invertible (i.e. to floating point
precision). Use a LUT for the per channel curves (such as the
original sRGB profile), and it's not quite perfectly invertible
(although it may be to low precision). Use cLUT based profiles,
and it certainly isn't. So it has to be declared to be
a special case and assumed to be a null transform.

* Deciding what does and doesn't correspond to a null transform
needs to be decided. Same exact profile ? Same tags ? Same
description string ? What ?

* If a surface straddles two displays, then labeling all the pixels
with one of the two displays profile is not the same as not
touching the pixels.

* What happens at startup, before the output display profiles are
loaded into the compositor, or if there is no display profile ?
How do you create a null transform to do an initial calibration
or profile ?

A simple "don't touch these pixels" flag avoids all this.
Post by Carsten Haitzler (The Rasterman)
extensions can be mandatory. if clients in the greater part cease to work at
all without the extension present and working in a specific way.
I don't see how any of that is an immediate or even long term issue. Wayland
applications work currently without any color management support. Adding such
support expands the range of applications (and hence users) that can use Wayland.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-15 02:40:33 UTC
Permalink
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
this == support for color correction protocol AND actually the support for
providing the real colorspace of the monitor, providing non SRGB pixel data
by clients in another colorspace (eg adobe) and it MUST work or apps will
literally fall over.
That's not a scheme I'm recommending.
ok. that's fine. i'm happy with that.

...snip...
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
not a format. a colorspce. R numbers are still R, as are G and B. it's just
that they point to different "real life spectrum" colors and so they need
to be transformed from one colorspace (sRGB to adobe RGB or adobe to sRGB).
My point stands. I've not mentioned new colorspaces.
if it's RGB or YUV (YCbCr) it's the same thing. just vastly different color
mechanisms. color correction in RGB space is actually the same as in YUV. it's
different spectrum points in space that the primaries point to.

color management require introducing such things. BT.601, BT.709, BT.2020.
the compositor MUST KNOW which colorspace the YUV data uses to get it correct.
i'm literally starting at datasheets of some hardware and you have to tell it
to use BT.601 or 709 equation when dealing with YUV. otherwise the video data
will look wrong. colors will be off. in fact BT.709 == sRGB.

now here comes the problem... each hardware plane yuv may be assigned to MAY
have a different colorspace. they also then get affected by the color
reproduction of the screen at the other end.

you HAVE to provide the colorspace information so the compositor CAN assign you
to the correct hw plane OR configure the plane correctly OR configure the
yuv->rgb conversion hardware to be correct.

this is no different to RGB space but you don't tend to find hardware
specifically helping you out (yes gpu + shader can do a transform fast. i'm
talking hw layers or dedicated acceleration units that have existed for yuv
for a long time).

any list of colorspaces IMHO should also include the yuv colorspaces where/if
possible. if a colorspace is not supported by the compositor then the appjust
needs to take a "best effort". the default colorspace today could be considered
BT.709/sRGB. also you could say "it's null transform" colorspace. i.e. you know
nothing so don't try colorcorrect.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
i really do not think this is needed. simply a list of available colorspaces
would be sufficient. application then provide data in the colorspace of it's
choice given what is supported by the compositor and the input data it has...
And I think it is core, for all the reasons I've listed.
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
enhanced: The compositor is provided with source colorspace
profiles by the application.
i again don't see why this is needed.
Hmm. How else does the compositor know how to transform from
the given colorspace to the display colorspace ?
my point was i don't think it's needed to split this up.

compositor lists available colorspaces. a list of 1 sRGB or null-transform or
adobe-rgb(with transform matrix), wide-gammut, etc. means thathat is the one
and only output supported.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
again - we're just arguing who does the transform.
It's not "just", it's the point.
not as i see it. given a choice of output colorspaces the client can choose to
do its own conversion, OR if it's colorspace of preference is supported by the
compositor then choose to pass the data in that colorspace to the compositor
and have the compositor do it.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
i don't see the point. the
compositor will have a list of colorspaces it can display (either A screen
can display this OR can be configured to display in this colorspace, ... OR
the compositor can software transform pixels in this colorspace to whatever
is necessary to display correctly).
I don't know how many different ways I can explain the same thing. The
compositor can't know how to transform color in all the ways an application
may need to transform color. I think it is unlikely for instance, that you are
proposing that the compositor support full N-Color, device links, ICC-Max
support, etc., or the infinity of ways that haven't been invented yet to
transform between color spaces. So the core color management requirement
is that the application be able to transform into the device colorspace itself.
*sigh* and THAT IS WHY i keep saying that the client can choose to do it's own!
BUT this is not going to be perfect across multiple screens unless all screens
share the same colorspace/profile. let's say:

1 screen is a professional grade monitor with wide gammut rgb output.
1 screen is a $50 thing i picked up from the bargain basement bin at walmart.

dumb compositor example:

compositor reports 2 colorspaces:
null transform RGB
BT.709 YUV

smart compositor:

compositor reports 5 colorspaces:
null transform RGB
wide gammut RGB
sRGB
BT.709 YUV
BT.601 YUV

in the dumb case your app can't do much. the smart case means that pixels
displaying on the pro montior either with null transform OR with wide gammut
colorspace get no transform done. pixels in sRGB, BT.709 and BT.601 have to be
transformed to the wide gammut rgb colorspace by the compositor. of course the
user would place the window on the best quality screen. within the color
spectrum the screens share colors SHOULD look identical.the client KNOWS the
colorspace being used and can transform/render data accordingly.

the user gets the exact effect you want - "perfect client-side handled colors"
if the app chooses wide gammut. this has the transform matrix/etc data needed
to do the client-side transforms. now if the compositor chooses NOT to
transform the data when the buffer is on other screens then the colors will
only look correct when placed on the professional monitor.

you CAN'T go rendering your buffer content differently based on screen
colorspace/profile. you may span multiple screens. your window may be rotated
at 37 degrees and perhaps be wrapped around 17 3d bunnyrabbits rotating around
ins space across 16 different screens.

the point of wayland is "every frame is perfect". you you want clients to
rendering their content differently based on what screen their window is on
then a compositor can NEVER get this right no matter how hared they try because
clients are fighting them and making assumptions they absolutely should not. i
already told you of more realistic cases of windows in miniature in pagers that
are not on the same screen as the full sized window (as opposed to the silly
bunnyrabit example above, but it's meant to make a point).

you HAVE to abstract/hide this kind of information to ALLOW the compositor to
get things right.

that is why i think the clients should not know what colorspace a specific
screen has at all. they should get an abstract list and the compositor "does
its best" (which may be nothing at all. it may be disallowing the window with a
buffer of that colorspace to leave the native screen that can display it, or to
emulate the colors by remapping etc.).

you get what you want - perfect colors ABLE to be managed/rendered/calculated
by the client using any algorithm/software/toolkit they like. they KNOW a
specific target colorspace and have to hope the compositor does the right thing.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
the client simply chooses what colorspace to provide buffers in. it chooses
the one that is best for it.
A core requirement is that the client be able to know what output device
colorspace each pixel is destined for, and provide a buffer that the
compositor doesn't touch (i.e. it has no source colorspace label
other than don't touch these pixels").
see above.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
a colorspace that is enabled is when the display output for that screen maps
RGB values directly to that given colorspace. i.e. the common default is sRGB.
No. No color transformation by the compositor, so no colorspace.
see above.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
the display may be also able to switch to adobe rgb at the flip of a switch
or by request from the host system (via data lines). it may be fixed and
only one colorspace is every able to be displayed.
A color critical user won't put up with such things - they expect to
be in control over what's happening, and if a system has proper
color management (core + enhanced), there is absolutely no
reason for them to run the display in anything other than it's native gamut.
a user actually should not have to deal with most of these issues at all. even
a color critical one. they likely shouldn't have to remember which one of their
16 screens has the best colorspace support for that image. the client can
choose to switch frame by frame from adobe rgb to srgb to wide gammut rub or
anything else. the compositor can then do whatever it thinks is best. just
because a compositor does things does not mean a user is not in control. the
compositor can provide such control to the user. just like photoshop can.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
then it's a list of 1 colorspace: "sRGB" :) wehich is the current
default/state of play in wayland anyway.
No, it's a list of N output display colorspaces, one for each display.
see above. it should not be per display.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
then you need no colormanagement at all.
As explained, yes, core color management needs support -
control over VideoLUT state, plus registration of the output
display colorspaces + knowledge of which output the different
parts of a surface map to.
as you describe "core color management" - it's not control. that's simple
passive reading of the state and providing to the client. control is when you
start determining the state of these.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
just assume sRGB (gamma2.2 or
whatever). zero colormanagement protocol or support needed. totally up to
client. the compositor MIGHT know its colorspace/profile and report it here
without sRGB listed then. thats how you know you only have 1 colorspace.
I'm not sure _what_ you are talking about. sRGB doesn't come into it.
sRGB is the colorspace of every HD display (or should be). how does it not come
into it?
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
how we're talking about color profiling tools that want to create a color
mapping/profile for that display so colors display correctly. you need a
colorimiter to measure output of course to do this.
Yes, and ?
you don't need anything special for color calibration beyond a null transform
and a compositor that won't go ignoring that null transform anyway for the
purpose of color calibration (when used by a calibration app).
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
this could be nothing more than a "1:1 do nothing" colorspace. that means
R,G and B values are transmitted with no changes. changing the content of
your buffer sends different signals that the colorimiter can read and thus
be used to create a color profile/mapping for your display.
Right - the sort of thing that is provided by a core/basic color
management support.
and it's nothing but yet another colorspace. think of it as the identity
matrix. nothing happens. it still is a listable colorspace.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
i don't get why you need so much complexity.
It's the simplest possible support, (hence calling it "core").
It's needed internally anyway for a compositor to implement CMM
operations for "enhance" color management.
it's also broken when you attach the color profile to a specific output. see
above.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
ummm i'm talking about the values of pixels. RGB. what physical color does
#ff0000 produce? #00ff00 or #0000ff or #880000 or #008800 etc. etc. - that
#is
what colormanagement is all about.
No it's not. That's just one aspect of it. The main game is in
how one device colorspace is transformed into another.
that's out of scope for wayland. HOW it is transformed is either done
client-side to present whatever source data in a given output colorspace to the
compositor OR it's done by the compositor to fix colorspaces provided by
clients to display as correctly as possible on a given screen + hardware.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
it's about knowing the physical wavelengths
of light produced when those values are displayed by a screen and then
ADJUSTING the values provided in order to display the correct physical color.
Hmm. Not really. Mostly a lot of other stuff has to go on top of that
to make things turn out how people expect (source colorspace definition,
white point mapping, gamut clipping or mapping, black point mapping etc.)
source definition is out of scope. that's up the the app (e.g. photoshop). the
colorspce defintition indeed covers what you say. and it is about adjusting. i
was saying the exact same thing. i am not unfamiliar with colorspaces, color
correction and mapping. it's necessary for YUV->RGB and is fundamentally the
same as RGB->RGB
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
a list of "just 1 colorspace" matches your core concept.
No. See above, and my original sketch.
1 colorspace which is the screen's output space is NOT the same? is that not
the same as a single screen system with the display colorspace on that 1
screen? how is it not the same? it's 1 colorspace exposed by compositor to
client in both cases. the SAME colorspace. how is this not the same?

the difference is that i dont think it should be per monitor. see above.
bunnies.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
the compositor MAY NOT transform. it doesnt have to. it can lie. as long as
it knows the colorspace/profile of the output and reports that as the one
and ONLY colorspace supported in the list, then you have what you want.
right?
It's a poor approach to rely on the "null transform" hack. It's clumsy,
doesn't convey the actual intent and expectation of operation, and leads
and that is why when a compositor DOES know the display colorspace it would
list that likely in addition to a null transform (there is basically no
downside to listing a null transform. it's the compositor just doing nothing
which is about as efficient as it gets). so other than the null transform list
the 1 colorspace which is what the screen supports - e.g. adobe rgb.
Post by Graeme Gill
* Null transform is a hack. Only under particular conditions
(matrix profile with equation defined per channel curves)
null is not a hack. it's useful for everyone who just doesn't care, and useful
for color calibration software to be able to display values on the screen
without any transform being done.

if the colorspace of a provided buffer == colorspace of output then it IS
effectively a null transform for the compositor and it does (or should do) just
that. thus client explicitly states what colorspace it wants for its buffer
after having queried the list of available ones.
Post by Graeme Gill
is a profile "exactly" invertible (i.e. to floating point
precision). Use a LUT for the per channel curves (such as the
original sRGB profile), and it's not quite perfectly invertible
(although it may be to low precision). Use cLUT based profiles,
and it certainly isn't. So it has to be declared to be
a special case and assumed to be a null transform.
no one is asking anyone to transform anything (thus invert or anything else)
with a null transform. and if colorspaces match no one is converting anything
either.
Post by Graeme Gill
* Deciding what does and doesn't correspond to a null transform
needs to be decided. Same exact profile ? Same tags ? Same
description string ? What ?
"colorspaces match". to me that means either a strictly standards defined
colorspace with fixed constants and both sides agree to use it, or its
something where the constants have adjustments based on doing a color profile
of the screen. in BOTH cases i argue that if you flatten the data into some
memory blob memcmp() == 0 if they match. the best way i see is the compositor
provides a list, client chooses and just says "i used the colorspace #6 you
told me". then it does match when on display/hardware that really exactly
physically matches. if it doesn't match compositor will have to "choose what to
do". see above.
Post by Graeme Gill
* If a surface straddles two displays, then labeling all the pixels
with one of the two displays profile is not the same as not
touching the pixels.
either way if the client is colorcorrecting itself based on the display output
it thinks it might be on (and it may be on many display outputs or wrapped
around bunnies)... then it WILL look incorrect on at LEAST one of those
displays at some point. and the point is to not look incorrect.
Post by Graeme Gill
* What happens at startup, before the output display profiles are
loaded into the compositor, or if there is no display profile ?
How do you create a null transform to do an initial calibration
or profile ?
at startup a compositor would load the color profiles that were
configured/stored from any previous execution that it knows match the displays
it has. you mean at setup time - like when someone buys a new monitor...

i'd have the compositor use a null transform (do nothing to rgb values) UNTIL
it has calibration data for that screen. you dont have to "create" a null
transform. it's just listed in the colorspaces supported. it is the "do
nothing" colorspace.
Post by Graeme Gill
A simple "don't touch these pixels" flag avoids all this.
why specialize it to a flag when it actually is just an "identity transform"
really which math-wise == no nothing as a fast path which is already what
compositors do.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
extensions can be mandatory. if clients in the greater part cease to work at
all without the extension present and working in a specific way.
I don't see how any of that is an immediate or even long term issue. Wayland
applications work currently without any color management support. Adding such
support expands the range of applications (and hence users) that can use Wayland.
let me roll back in time. long ago in a land far far away i was working with
x11 systems... and you then found some x11 apps that refused to work on your
xserver... because they NEEDED an 8bpp visual, but your display was just a 1
bit mono one? no emulation. apps were specifically bound to a specific depth
because thats how x11 worked. it strictly defined the output pixel value of
operations so emulation was disallowed. result - you cant run the app at all.
the not long after i had 8bpp x11 apps that refused to run on 16bpp. they also
didn't work on 1bpp. hooray! i ended up actually porting quake to 16bpp myself
(i had some ... let's say dubiously obtained source to have a linux and even
solaris/sparc (8bbp), osf1/alpha(8bpp) and linux/ix86(16bpp) port of quake to
x11...).

the problem was that you ended up with apps that just refused to work and if
i didn't have source and the time and desire to fix them, they would have
continued to not work and if i was a regular user i would likely have just
sworn and gotten unhappy and eventually moved to a platform where this doesn't
happen.

i do not want to see this kind of thing happen again in wayland land. that's
why it matters to me. it leads to a frustrating user experience.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Niels Ole Salscheider
2016-12-18 15:25:13 UTC
Permalink
I feel like the discussion drifts off a bit. You (Graeme) obviously know much
more about color management than I do. But as Pekka already pointed out there
are a few constraints that originate in the design decisions of wayland and
are quite different to these of X11. We can't change these constraints but
have to find a solution that works well with them:

- A normal application CANNOT control the hardware directly (it can't program
LUTs, for example).

- A normal application CANNOT alter global settings of the compositor (like
setting color profiles for the outputs). This can only be done by the
compositor or a few trusted applications. The user will just have to use the
settings dialog provided with the compositor. Because of that it does not
matter if this is implementation dependent.

- You DO NOT know which parts of a surface are shown on which screen.

- We aim to be pixel-perfect.

I think these constraints mean that we must let the compositor take part in
the color correction, at least if more than one screen is involved. If we do
so, we should also be able to expect that the compositor can handle a bit more
complicated cases (e. g. an arbitrary number of different surfaces with
different color profiles).

When I proposed this protocol my focus was on applications that may not be
color managed currently. I thought for example about web browsers or simple
image viewers where I would view (but not edit) photos.
Your focus is obviously on professional applications. I think both use cases
are equally important and we should not treat one as an afterthought of the
other.

I would be glad if we could come up with a solution that works for both under
these constraints.
Carsten Haitzler (The Rasterman)
2016-12-18 23:31:26 UTC
Permalink
On Sun, 18 Dec 2016 16:25:13 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
I feel like the discussion drifts off a bit. You (Graeme) obviously know much
more about color management than I do. But as Pekka already pointed out there
are a few constraints that originate in the design decisions of wayland and
are quite different to these of X11. We can't change these constraints but
- A normal application CANNOT control the hardware directly (it can't program
LUTs, for example).
- A normal application CANNOT alter global settings of the compositor (like
setting color profiles for the outputs). This can only be done by the
compositor or a few trusted applications. The user will just have to use the
settings dialog provided with the compositor. Because of that it does not
matter if this is implementation dependent.
- You DO NOT know which parts of a surface are shown on which screen.
- We aim to be pixel-perfect.
I think these constraints mean that we must let the compositor take part in
the color correction, at least if more than one screen is involved. If we do
so, we should also be able to expect that the compositor can handle a bit
more complicated cases (e. g. an arbitrary number of different surfaces with
different color profiles).
bingo. and while we're at it we should solve our yuv colorspace issues too
(same as rgb. currently bt601, bt709 and bt2020 need supporting).
Post by Niels Ole Salscheider
When I proposed this protocol my focus was on applications that may not be
color managed currently. I thought for example about web browsers or simple
image viewers where I would view (but not edit) photos.
Your focus is obviously on professional applications. I think both use cases
are equally important and we should not treat one as an afterthought of the
other.
I would be glad if we could come up with a solution that works for both under
these constraints.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-20 23:33:47 UTC
Permalink
Maybe the device link is kind of a extension for later implementation.
I'm not enthused by that - I'd rather have it there right from the
start if no other practical means of an application doing the
color conversion itself. To do otherwise means that it will never be
uniformly supported, and relegates Wayland to being second class for
color critical applications.

In terms of the compositor support needed, I don't see it as adding
any significant extra complexity - the processing needed is simpler
in many ways to the device profile case - no linking is needed.
There is just a little extra book keeping in storing one
device link per Output, and using it in preference to the
device profile if it is present.

One of my concerns about this approach is whether it limits the
precision of the conversion in ways that do not apply if
the application is able to do the conversion. HDR is arriving,
so this could be important if it turns out that current
ICC V2 and V4 is insufficient in some way. ICC Max is
too immature at the moment to write into a spec., although
it is moving along. (The presentations at ICC DevCon in
San Diego were interesting from that point of view.)

Graeme Gill.
James Feeney
2016-12-18 17:25:17 UTC
Permalink
Post by Niels Ole Salscheider
as Pekka already pointed out there
are a few constraints that originate in the design decisions of wayland and
are quite different to [those] of X11. We can't change these constraints but
have to find a solution that works well with them: ...
I'm more of a bystander to this discussion. It would be really nice to have a
shared working document, to follow along, showing
1) a list of Wayland design requirements and constraints for color, and
2) a complete list steps needed to process an image, from source to display,
3) distinguishing issues like color gamut from color encoding.

From there, it would be much easier for people to see where "standard interface"
lines are being drawn, to see what steps are being handled by the compositor vs
an application, to see what steps are automatic and which steps must be manually
configured, and to distinguish what *should be* happening, and to see whether
anything was "missing", in the processing chain.

It is unfortunate that we are all still "stuck in the stone age", exchanging
black and white text documents with email, without the tools needed to draw and
view nice graphics for block diagrams and such. It is what it is. Still, some
clever use of ordered lists can go a long way to creating an understandable
sequence with groupings.

Would someone knowledgeable be willing to draft a "Wayland Pixel Perfect Color
Processing Chain" working document and post it somewhere conspicuously? I'm
thinking that someone already knows enough to just rattle this off, from memory?

Or, is that document already posted somewhere?
Niels Ole Salscheider
2016-12-09 13:06:46 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
i'm curious... is the intent to make it requird that all compositors
support color management (and thus have to support all the possible
colorspaces>
I'd be happy if there was support for core color management (i.e.
application color management), before adding layers that depend on the
core.
but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client? or will it be expected that apps need
to always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?
We can't make support for this protocol mandatory because color correction
might be too much overhead for compositors for embedded devices.

But I would say that every compositor that does some sort of color correction
should also implement the color management protocol.
If the protocol is not supported by the compositor you would assume that you
have to output the colors in the device color space (or just ignore it if you
do not care about accurate colors).
Carsten Haitzler (The Rasterman)
2016-12-10 02:19:14 UTC
Permalink
On Fri, 09 Dec 2016 14:06:46 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
i'm curious... is the intent to make it requird that all compositors
support color management (and thus have to support all the possible
colorspaces>
I'd be happy if there was support for core color management (i.e.
application color management), before adding layers that depend on the
core.
but is the intent that compositors MUST support color management and
applications will fail entirely or fail to display even partly correctly if
compositor doesnt support color management or doesnt support the color
profile/space requested by the client? or will it be expected that apps need
to always be able to convert to sRGB for compatibility and then have added
colorspace capabilities if it's supported? what is the intent?
We can't make support for this protocol mandatory because color correction
might be too much overhead for compositors for embedded devices.
well graeme disagrees and effectively thinks it should be. :)
Post by Niels Ole Salscheider
But I would say that every compositor that does some sort of color correction
should also implement the color management protocol.
If the protocol is not supported by the compositor you would assume that you
have to output the colors in the device color space (or just ignore it if you
do not care about accurate colors).
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-13 06:28:20 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
well graeme disagrees and effectively thinks it should be. :)
I said no such thing!

Graeme Gill.
Graeme Gill
2016-12-12 06:23:21 UTC
Permalink
Post by Niels Ole Salscheider
But I would say that every compositor that does some sort of color correction
should also implement the color management protocol.
If the protocol is not supported by the compositor you would assume that you
have to output the colors in the device color space (or just ignore it if you
do not care about accurate colors).
I want to see the latter supported before the former.

Graeme Gill.
Graeme Gill
2016-12-08 04:51:12 UTC
Permalink
Post by Niels Ole Salscheider
Therefore I think that the situation has changed and I'd like to propose this
protocol for inclusion in wayland-protocols again.
What do you think?
Hi,
I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
Post by Niels Ole Salscheider
About this; in the near future systems will be migrating from X11 to
Wayland (Fedora 25 already defaults to Wayland, other distros will
follow) and so setting X atoms is no longer going to work. Even with
XWayland (the compatibility "wrapper" that provides an isolated
xserver for the app) you can't use the root window as it's isolated
from the other windows. I think most applications that want to know
what profile to use are now using either libcolord, or more commonly,
the colord DBus API.
What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.

Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]

It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.

So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
system such as Wayland are:

* That color management protocol's have two uses :- 1) configuring
color management and 2) allowing applications to use color management.
These two uses may need different security profiles.
The assumption should be that color management applications
used to create calibrations, profiles and configure the
state of color management, are of equal importance to color
managed applications that depend on a properly profiled and
configured color management system, since you can't have latter
with out the former.

* Color management of a graphics rendering system such as Wayland
should be split into two levels (possibly two extensions) :-

1) Core == output device management, which involves identifying output devices,
controlling their calibration state (Video LUT), installing a color profile
resources associated with that output device, and identifying which rendered
pixels go to which output device(s). This is the most basic requirement, since
this is the bare minimum for applications to be properly color managed. It
is also a necessary resource for the second level to be able to operate.

2) Enhanced == input space management, which assumes a graphics
server rendering system capable of color management. This involves labeling
an input raster with a color profile, and controlling the manner of
rendering (i.e. rendering intent, maybe blending space ? etc.) This is useful
for implementing default color management (e.g. as a means of coping
with wide gamut displays when many applications are not color aware),
or as a low developer overhead means of implementing basic color
management in non color critical applications.

Translating these aims into a more concrete set of capabilities might
look like this:

Core:
Get corresponding CRTC regions for a given Surface.
Get corresponding Output(s) for a CRTC.
Get unique Monitor identifier for an Output (i.e. EDID)
Get/Set CRTC per channel lookup tables.
Clear/Set/Get ICC profile associated with an Output.

Event notifications:
- CRTC to surface mapping change
- Output to CRTC mapping change
- Monitor to Output connection change
- ICC profile associated with Output change

Enhanced:
Clear/Set/Get default color management source RGB ICC profile for a display.
Disable/Enable/UseDefault color management flag for a Surface.
Clear/Set/Get source RGB ICC profile for a Surface.
Set/Get source and destination rendering intents for a Surface.

Given that Wayland doesn't seem to have current support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.

Graeme Gill.
Niels Ole Salscheider
2016-12-09 13:38:37 UTC
Permalink
Post by Graeme Gill
Post by Niels Ole Salscheider
Therefore I think that the situation has changed and I'd like to propose
this protocol for inclusion in wayland-protocols again.
What do you think?
Hi,
I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
Post by Niels Ole Salscheider
About this; in the near future systems will be migrating from X11 to
Wayland (Fedora 25 already defaults to Wayland, other distros will
follow) and so setting X atoms is no longer going to work. Even with
XWayland (the compatibility "wrapper" that provides an isolated
xserver for the app) you can't use the root window as it's isolated
from the other windows. I think most applications that want to know
what profile to use are now using either libcolord, or more commonly,
the colord DBus API.
What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.
Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]
It is (currently) up to the compositor to decide how to implement this. The
compositor could come with its own settings for the output color profiles or
query some other program. This might be colord, but it could also be
kolormanager, or something else.
Post by Graeme Gill
It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.
Yes, with the protocol I proposed there is a (small) time window after
changing the output color space where the application might still display
surfaces with the old color space...
Post by Graeme Gill
So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
* That color management protocol's have two uses :- 1) configuring
color management and 2) allowing applications to use color management.
These two uses may need different security profiles.
The assumption should be that color management applications
used to create calibrations, profiles and configure the
state of color management, are of equal importance to color
managed applications that depend on a properly profiled and
configured color management system, since you can't have latter
with out the former.
* Color management of a graphics rendering system such as Wayland
should be split into two levels (possibly two extensions) :-
1) Core == output device management, which involves identifying output
devices, controlling their calibration state (Video LUT), installing a
color profile resources associated with that output device, and identifying
which rendered pixels go to which output device(s). This is the most basic
requirement, since this is the bare minimum for applications to be properly
color managed. It is also a necessary resource for the second level to be
able to operate.
2) Enhanced == input space management, which assumes a graphics
server rendering system capable of color management. This involves
labeling an input raster with a color profile, and controlling the manner
of rendering (i.e. rendering intent, maybe blending space ? etc.) This is
useful for implementing default color management (e.g. as a means of coping
with wide gamut displays when many applications are not color aware), or as
a low developer overhead means of implementing basic color management in
non color critical applications.
Translating these aims into a more concrete set of capabilities might
Get corresponding CRTC regions for a given Surface.
Get corresponding Output(s) for a CRTC.
Get unique Monitor identifier for an Output (i.e. EDID)
Get/Set CRTC per channel lookup tables.
Clear/Set/Get ICC profile associated with an Output.
- CRTC to surface mapping change
- Output to CRTC mapping change
- Monitor to Output connection change
- ICC profile associated with Output change
Clear/Set/Get default color management source RGB ICC profile for a
display. Disable/Enable/UseDefault color management flag for a Surface.
Clear/Set/Get source RGB ICC profile for a Surface.
Set/Get source and destination rendering intents for a Surface.
Given that Wayland doesn't seem to have current support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Carsten Haitzler (The Rasterman)
2016-12-10 02:48:32 UTC
Permalink
On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
Post by Graeme Gill
Post by Niels Ole Salscheider
Therefore I think that the situation has changed and I'd like to propose
this protocol for inclusion in wayland-protocols again.
What do you think?
Hi,
I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
Post by Niels Ole Salscheider
About this; in the near future systems will be migrating from X11 to
Wayland (Fedora 25 already defaults to Wayland, other distros will
follow) and so setting X atoms is no longer going to work. Even with
XWayland (the compatibility "wrapper" that provides an isolated
xserver for the app) you can't use the root window as it's isolated
from the other windows. I think most applications that want to know
what profile to use are now using either libcolord, or more commonly,
the colord DBus API.
What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.
Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]
It is (currently) up to the compositor to decide how to implement this. The
compositor could come with its own settings for the output color profiles or
query some other program. This might be colord, but it could also be
kolormanager, or something else.
Post by Graeme Gill
It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.
Yes, with the protocol I proposed there is a (small) time window after
changing the output color space where the application might still display
surfaces with the old color space...
wouldn't it be best not to explicitly ask for an output colorspace and just
provide the colorspace of your buffer and let the compositor decide? e.g. if
your window is on top, or it's the largest one, or it's focused,then the
compositor MAY switch the colorspace of that monitor to match your surface's
buffer colorspace, and if it goes into the background or whatever, switch back?
it can (and likely should) emulato other colorspaced then.

e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
re-render everything else that is sRGB into adobe argb space... there might be
a slight "flicker" so to speak as maybe some banding appears in some gradients
of SRGB windows or colors are ever so slightly off, but the compositor is
optimizing for the surface it thinks it most important. i really don't like the
idea of applications explicitly controlling screen colorspace. simple being
able to list colorspaces available, know which might be native or emulated, and
then say which colorspace their buffer has. this way colorspace is tired
directly to the buffer and the compositor can avoid these glitches (like time
difference between switching screen colorspace and buffers actually being
provided in that colorspace).
Post by Niels Ole Salscheider
Post by Graeme Gill
So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
* That color management protocol's have two uses :- 1) configuring
color management and 2) allowing applications to use color management.
These two uses may need different security profiles.
The assumption should be that color management applications
used to create calibrations, profiles and configure the
state of color management, are of equal importance to color
managed applications that depend on a properly profiled and
configured color management system, since you can't have latter
with out the former.
* Color management of a graphics rendering system such as Wayland
should be split into two levels (possibly two extensions) :-
1) Core == output device management, which involves identifying output
devices, controlling their calibration state (Video LUT), installing a
color profile resources associated with that output device, and identifying
which rendered pixels go to which output device(s). This is the most basic
requirement, since this is the bare minimum for applications to be properly
color managed. It is also a necessary resource for the second level to be
able to operate.
2) Enhanced == input space management, which assumes a graphics
server rendering system capable of color management. This involves
labeling an input raster with a color profile, and controlling the manner
of rendering (i.e. rendering intent, maybe blending space ? etc.) This is
useful for implementing default color management (e.g. as a means of coping
with wide gamut displays when many applications are not color aware), or as
a low developer overhead means of implementing basic color management in
non color critical applications.
Translating these aims into a more concrete set of capabilities might
Get corresponding CRTC regions for a given Surface.
Get corresponding Output(s) for a CRTC.
Get unique Monitor identifier for an Output (i.e. EDID)
Get/Set CRTC per channel lookup tables.
Clear/Set/Get ICC profile associated with an Output.
- CRTC to surface mapping change
- Output to CRTC mapping change
- Monitor to Output connection change
- ICC profile associated with Output change
Clear/Set/Get default color management source RGB ICC profile for a
display. Disable/Enable/UseDefault color management flag for a Surface.
Clear/Set/Get source RGB ICC profile for a Surface.
Set/Get source and destination rendering intents for a Surface.
Given that Wayland doesn't seem to have current support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Niels Ole Salscheider
2016-12-10 08:50:53 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
Post by Graeme Gill
Post by Niels Ole Salscheider
Therefore I think that the situation has changed and I'd like to propose
this protocol for inclusion in wayland-protocols again.
What do you think?
Hi,
I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
Post by Niels Ole Salscheider
About this; in the near future systems will be migrating from X11 to
Wayland (Fedora 25 already defaults to Wayland, other distros will
follow) and so setting X atoms is no longer going to work. Even with
XWayland (the compatibility "wrapper" that provides an isolated
xserver for the app) you can't use the root window as it's isolated
from the other windows. I think most applications that want to know
what profile to use are now using either libcolord, or more commonly,
the colord DBus API.
What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.
Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]
It is (currently) up to the compositor to decide how to implement this. The
compositor could come with its own settings for the output color profiles
or query some other program. This might be colord, but it could also be
kolormanager, or something else.
Post by Graeme Gill
It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.
Yes, with the protocol I proposed there is a (small) time window after
changing the output color space where the application might still display
surfaces with the old color space...
wouldn't it be best not to explicitly ask for an output colorspace and just
provide the colorspace of your buffer and let the compositor decide? e.g. if
your window is on top, or it's the largest one, or it's focused,then the
compositor MAY switch the colorspace of that monitor to match your
surface's buffer colorspace, and if it goes into the background or
whatever, switch back? it can (and likely should) emulato other colorspaced
then.
I think there is a misconception here. For normal applications it would work
like this:
surface color space -> blending colorspace (where the compositor does
blending) -> output color space.
If the application is fullscreen then the compositor does not need to do
blending and can just do the surface color space -> output color space
conversion.

But Graeme talked about professional applications that want to do color
management on their own because they have more complex needs.
These application would query the output color space of the screen that they
are currently on and do all conversions on their own.
These applications would not want the compositor to do anything to the colors
and indicate this (implicitly) by setting the surface color space to the
output colorspace.
Post by Carsten Haitzler (The Rasterman)
e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
re-render everything else that is sRGB into adobe argb space... there might
be a slight "flicker" so to speak as maybe some banding appears in some
gradients of SRGB windows or colors are ever so slightly off, but the
compositor is optimizing for the surface it thinks it most important. i
really don't like the idea of applications explicitly controlling screen
colorspace. simple being able to list colorspaces available, know which
might be native or emulated, and then say which colorspace their buffer
has. this way colorspace is tired directly to the buffer and the compositor
can avoid these glitches (like time difference between switching screen
colorspace and buffers actually being provided in that colorspace).
Post by Niels Ole Salscheider
Post by Graeme Gill
So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
* That color management protocol's have two uses :- 1) configuring
color management and 2) allowing applications to use color management.
These two uses may need different security profiles.
The assumption should be that color management applications
used to create calibrations, profiles and configure the
state of color management, are of equal importance to color
managed applications that depend on a properly profiled and
configured color management system, since you can't have latter
with out the former.
* Color management of a graphics rendering system such as Wayland
should be split into two levels (possibly two extensions) :-
1) Core == output device management, which involves identifying output
devices, controlling their calibration state (Video LUT), installing a
color profile resources associated with that output device, and identifying
which rendered pixels go to which output device(s). This is the most basic
requirement, since this is the bare minimum for applications to be properly
color managed. It is also a necessary resource for the second level to be
able to operate.
2) Enhanced == input space management, which assumes a graphics
server rendering system capable of color management. This involves
labeling an input raster with a color profile, and controlling the manner
of rendering (i.e. rendering intent, maybe blending space ? etc.) This is
useful for implementing default color management (e.g. as a means of coping
with wide gamut displays when many applications are not color aware), or as
a low developer overhead means of implementing basic color management in
non color critical applications.
Translating these aims into a more concrete set of capabilities might
Get corresponding CRTC regions for a given Surface.
Get corresponding Output(s) for a CRTC.
Get unique Monitor identifier for an Output (i.e. EDID)
Get/Set CRTC per channel lookup tables.
Clear/Set/Get ICC profile associated with an Output.
- CRTC to surface mapping change
- Output to CRTC mapping change
- Monitor to Output connection change
- ICC profile associated with Output change
Clear/Set/Get default color management source RGB ICC profile for a
display. Disable/Enable/UseDefault color management flag for a Surface.
Clear/Set/Get source RGB ICC profile for a Surface.
Set/Get source and destination rendering intents for a Surface.
Given that Wayland doesn't seem to have current support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Carsten Haitzler (The Rasterman)
2016-12-11 02:13:17 UTC
Permalink
On Sat, 10 Dec 2016 09:50:53 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
Post by Carsten Haitzler (The Rasterman)
On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
Post by Niels Ole Salscheider
Post by Graeme Gill
Post by Niels Ole Salscheider
Therefore I think that the situation has changed and I'd like to propose
this protocol for inclusion in wayland-protocols again.
What do you think?
Hi,
I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
Post by Niels Ole Salscheider
About this; in the near future systems will be migrating from X11 to
Wayland (Fedora 25 already defaults to Wayland, other distros will
follow) and so setting X atoms is no longer going to work. Even with
XWayland (the compatibility "wrapper" that provides an isolated
xserver for the app) you can't use the root window as it's isolated
from the other windows. I think most applications that want to know
what profile to use are now using either libcolord, or more commonly,
the colord DBus API.
What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.
Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]
It is (currently) up to the compositor to decide how to implement this. The
compositor could come with its own settings for the output color profiles
or query some other program. This might be colord, but it could also be
kolormanager, or something else.
Post by Graeme Gill
It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.
Yes, with the protocol I proposed there is a (small) time window after
changing the output color space where the application might still display
surfaces with the old color space...
wouldn't it be best not to explicitly ask for an output colorspace and just
provide the colorspace of your buffer and let the compositor decide? e.g. if
your window is on top, or it's the largest one, or it's focused,then the
compositor MAY switch the colorspace of that monitor to match your
surface's buffer colorspace, and if it goes into the background or
whatever, switch back? it can (and likely should) emulato other colorspaced
then.
I think there is a misconception here. For normal applications it would work
surface color space -> blending colorspace (where the compositor does
blending) -> output color space.
If the application is fullscreen then the compositor does not need to do
blending and can just do the surface color space -> output color space
conversion.
actually... all the major toolkits and apps work in ARGB premul (which is SRGB
with gamma 2.2 or whatever - the non-linear one). they actually work natively
in that space so they are producing what i have, for short, called "sRGB
buffers" (sARGB premul?). so this is currently the native colorspace for all
wayland compositors, client buffers AND for actual monitors.

what we're talking about here is clients providing buffers in ANOTHER RGB
colorspace. this is exactly the same as YUV (actually there's BT601 and BT709
YUV/YCbCr colorspace depending on SD vs HD, and in fact there's also now a
BT2020 for UHD. in fact this is a problem in wayland right now as there way i
know of to distinguish the colorspace of a YUV buffer - is it 601, 709 .. or
2020?

this is the same issue with RGB colorspaces. totally the same. the difference
is that the various YUV colorspaces are far more widespread than specialized
RGB colorspaces. in the end generally with yuv it either is handedoff to yuv
plane hardware to deal with to convert to regular RGB output signal or it's
converted with software or fragment shaders. no matter what, unless you have
hardware plane support you need to do a conversion which can be "not that
cheap" if you have to do it on the cpu.
Post by Niels Ole Salscheider
But Graeme talked about professional applications that want to do color
management on their own because they have more complex needs.
why do they want to MANAGE color. all they need is to PRESENT their content in
their preferred colospace. let's think adobe RGB. if photoshop/gimp/whatever
has an image that is set to be in this colorspace then it can either switch its
entire window to adobe rgb (and appropriately alter controls/button/icons and
what not to look right) or use a subsurface just for the image in this
colorspace.

*IF* the monitor is adobe rgb capable, the compositor can pass through this
surface buffer without modification. 1:1 pixel values to the framebuffer (or
assign to a hw layer maybe). perhaps the screen has to be configured to be in a
different colorspace and the compositor can do this at this time. if this is
not possible then the compositor will have to downconvert the adobe rgb data to
sRGB for display. the client needs not CONTROL over the screen. the compositor
handles that.

this is also no different to a client providing 24/32bpp buffers but the screen
being 18bpp, 16bpp, 15bpp or 8bpp or pure 1bit monochrome.

the compositor will downconvert to these color formats and dither or whatever.

of course this relies on the compositor supporting that colorspace. so all that
is really needed is:

1. list of colorspaces supported (and which ones can be native to the screen)
2. the ability to tag a buffer with a colorspace (needed for yuv too as above).

there is no need for an application to know the current colorspace of the
screen - just what is possible (perhaps it can do 3 or 4 different ones? maybe
only 1? but no need to know the CURRENT one), and no need to directly CONTROL
he current colorspace. leave that to the compositor. just attach colorspace to
the buffer.
Post by Niels Ole Salscheider
These application would query the output color space of the screen that they
are currently on and do all conversions on their own.
just PROVIDE a buffer in that colorspace... what the app does to make this
happen is totally up tot he app itself... :)
Post by Niels Ole Salscheider
These applications would not want the compositor to do anything to the colors
and indicate this (implicitly) by setting the surface color space to the
output colorspace.
attach to the buffer not the surface. cleaner :) as the content of the buffer
has been rendered in that colorspace... right? :)

the compositor may still do things to the pixels in the buffer when drawing if
the colorspace of the screen at the time is not the same as the buffer
colorspace. :)
Post by Niels Ole Salscheider
Post by Carsten Haitzler (The Rasterman)
e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
re-render everything else that is sRGB into adobe argb space... there might
be a slight "flicker" so to speak as maybe some banding appears in some
gradients of SRGB windows or colors are ever so slightly off, but the
compositor is optimizing for the surface it thinks it most important. i
really don't like the idea of applications explicitly controlling screen
colorspace. simple being able to list colorspaces available, know which
might be native or emulated, and then say which colorspace their buffer
has. this way colorspace is tired directly to the buffer and the compositor
can avoid these glitches (like time difference between switching screen
colorspace and buffers actually being provided in that colorspace).
Post by Niels Ole Salscheider
Post by Graeme Gill
So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
* That color management protocol's have two uses :- 1) configuring
color management and 2) allowing applications to use color management.
These two uses may need different security profiles.
The assumption should be that color management applications
used to create calibrations, profiles and configure the
state of color management, are of equal importance to color
managed applications that depend on a properly profiled and
configured color management system, since you can't have latter
with out the former.
* Color management of a graphics rendering system such as Wayland
should be split into two levels (possibly two extensions) :-
1) Core == output device management, which involves identifying output
devices, controlling their calibration state (Video LUT), installing a
color profile resources associated with that output device, and identifying
which rendered pixels go to which output device(s). This is the most basic
requirement, since this is the bare minimum for applications to be properly
color managed. It is also a necessary resource for the second level to be
able to operate.
2) Enhanced == input space management, which assumes a graphics
server rendering system capable of color management. This involves
labeling an input raster with a color profile, and controlling the manner
of rendering (i.e. rendering intent, maybe blending space ? etc.) This is
useful for implementing default color management (e.g. as a means of coping
with wide gamut displays when many applications are not color aware), or as
a low developer overhead means of implementing basic color management in
non color critical applications.
Translating these aims into a more concrete set of capabilities might
Get corresponding CRTC regions for a given Surface.
Get corresponding Output(s) for a CRTC.
Get unique Monitor identifier for an Output (i.e. EDID)
Get/Set CRTC per channel lookup tables.
Clear/Set/Get ICC profile associated with an Output.
- CRTC to surface mapping change
- Output to CRTC mapping change
- Monitor to Output connection change
- ICC profile associated with Output change
Clear/Set/Get default color management source RGB ICC profile for a
display. Disable/Enable/UseDefault color management flag for a Surface.
Clear/Set/Get source RGB ICC profile for a Surface.
Set/Get source and destination rendering intents for a Surface.
Given that Wayland doesn't seem to have current support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-13 06:46:25 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
wouldn't it be best not to explicitly ask for an output colorspace and just
provide the colorspace of your buffer and let the compositor decide? e.g. if
your window is on top, or it's the largest one, or it's focused,then the
compositor MAY switch the colorspace of that monitor to match your surface's
buffer colorspace, and if it goes into the background or whatever, switch back?
it can (and likely should) emulato other colorspaced then.
That doesn't seem like color management. Ultimately you arrive
at the native display space, so if things are to look as intended,
something (application or compositor) should transform from
a non-native spaces into the native space.

At a practical level, if it is expected that the compositor
deals with transparency (which I assume it does), then I'd
suggest something simple - compositing in output device space
(Isn't that what current Wayland compositors are doing ?),
or as a refinement, compositing in a per-channel light
linearised space, that is reversible at the bit level.

Bottom line is that a color critical application won't
use compositor transparency for anything it cares about.
Post by Carsten Haitzler (The Rasterman)
e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
re-render everything else that is sRGB into adobe argb space... there might be
a slight "flicker" so to speak as maybe some banding appears in some gradients
of SRGB windows or colors are ever so slightly off, but the compositor is
optimizing for the surface it thinks it most important.
Sounds cumbersome. It's certainly not how existing systems work.
Post by Carsten Haitzler (The Rasterman)
i really don't like the
idea of applications explicitly controlling screen colorspace.
I'm not sure what you mean by that. Traditionally applications render
to the display colorspace. Changing the display setup (i.e. switching
display colorspace emulation) is a user action, complicated only by the
need to make the corresponding change to the display profile, and re-rendering
anything that depends on the display profile.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-14 07:10:33 UTC
Permalink
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
wouldn't it be best not to explicitly ask for an output colorspace and just
provide the colorspace of your buffer and let the compositor decide? e.g. if
your window is on top, or it's the largest one, or it's focused,then the
compositor MAY switch the colorspace of that monitor to match your surface's
buffer colorspace, and if it goes into the background or whatever, switch
back? it can (and likely should) emulato other colorspaced then.
That doesn't seem like color management. Ultimately you arrive
at the native display space, so if things are to look as intended,
something (application or compositor) should transform from
a non-native spaces into the native space.
At a practical level, if it is expected that the compositor
deals with transparency (which I assume it does), then I'd
suggest something simple - compositing in output device space
(Isn't that what current Wayland compositors are doing ?),
a display may not have a single native colorspace. it may be able to switch.
embedded devices can do this as the display panel may have extra control lines
for switching to a different display gammut/profile. it may be done at the gfx
card output level too... so it can change on the fly.

yes. compositors right now work in display colorspace. they do no conversions.
eventually they SHOULD to display correctly. to do so they need a color profile
for the display.

it may be that a window spans 8 different screens all with different profiles.
then what? currently the image looks a bit different on each display. with a
proper color correcting compositor it can make them all look the same. if you
want apps to be able to provide "raw in screen colorspace pixels" this is going
to be horrible especially as windows span multilpe screens. if i mmove the
window around the client has drawn different parts of its buffer with different
colorspaces/profiles in mind and then has to keep redrawing to adjust as it
moves. you'll be ablew to see "trails" of incorrect coloring around the
boundaries of the screens untl the client catches up.

the compositor SHOULD do any color correction needed at this point. if you want
PROPER color correction the compositor at a MINIMUM needs to be able to report
the color profile of a screen even if it does no correcting. yes you may have
multiple screens. i really dislike the above scenario of incorrect pixel tails
because this goes against the whole philosophy of "every frame is perfect". you
cannot do this given your proposal. it can only be done if the compositor
handles the color correction and the clients just provide the colorspace being
used for their pixel data.
Post by Graeme Gill
or as a refinement, compositing in a per-channel light
linearised space, that is reversible at the bit level.
Bottom line is that a color critical application won't
use compositor transparency for anything it cares about.
i'm totally ignoring the case of having alpha. yes. blending in gamma space is
"wrong". but it's fast. :)
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
e.g. if buffer is adobe rgb, then switch display to work in adobe rgb but
re-render everything else that is sRGB into adobe argb space... there might
be a slight "flicker" so to speak as maybe some banding appears in some
gradients of SRGB windows or colors are ever so slightly off, but the
compositor is optimizing for the surface it thinks it most important.
Sounds cumbersome. It's certainly not how existing systems work.
Post by Carsten Haitzler (The Rasterman)
i really don't like the
idea of applications explicitly controlling screen colorspace.
I'm not sure what you mean by that. Traditionally applications render
to the display colorspace. Changing the display setup (i.e. switching
display colorspace emulation) is a user action, complicated only by the
need to make the corresponding change to the display profile, and re-rendering
anything that depends on the display profile.
being able to modify what the screen colorspace is in any way is what i
dislike. only the compositor should affect this based on it's own decisions.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-12 07:18:21 UTC
Permalink
Post by Niels Ole Salscheider
Post by Graeme Gill
Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]
It is (currently) up to the compositor to decide how to implement this. The
compositor could come with its own settings for the output color profiles or
query some other program. This might be colord, but it could also be
kolormanager, or something else.
1) This doesn't address how this information is communicated
to a Wayland application.

2) Expecting color management applications to deal with
configuring the compositor in a platform dependent
way, is expecting far too much. I for one am not
about to add multiple platform dependent back
ends (multiple flavors of Linux, BSD's, Android,
etc.) to my tools to do this, and no other major
platform expects it (i.e. none of MSWindows, OS X
or X11 based systems have this requirement.)

The correct approach to avoiding such issues is simply
to make both aspects Wayland (extension) protocols, so
that Wayland color management and color sensitive applications
have the potential to work across all Wayland systems,
rather than being at best balkanized, or at worst, not
supported.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-13 03:05:36 UTC
Permalink
Post by Graeme Gill
Post by Niels Ole Salscheider
Post by Graeme Gill
Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]
It is (currently) up to the compositor to decide how to implement this. The
compositor could come with its own settings for the output color profiles
or query some other program. This might be colord, but it could also be
kolormanager, or something else.
1) This doesn't address how this information is communicated
to a Wayland application.
2) Expecting color management applications to deal with
configuring the compositor in a platform dependent
way, is expecting far too much. I for one am not
about to add multiple platform dependent back
ends (multiple flavors of Linux, BSD's, Android,
etc.) to my tools to do this, and no other major
platform expects it (i.e. none of MSWindows, OS X
or X11 based systems have this requirement.)
The correct approach to avoiding such issues is simply
to make both aspects Wayland (extension) protocols, so
that Wayland color management and color sensitive applications
have the potential to work across all Wayland systems,
rather than being at best balkanized, or at worst, not
supported.
"not supported" == sRGB (gamma). render appropriately. most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
either compositor will fake it and reduce your colors down to sRGB, or your
apps produce sRGB by default and have code paths for extended colorspace
support *IF* it exists AND different colorspaces are natively supported by the
display hardware.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Graeme Gill
2016-12-14 07:27:13 UTC
Permalink
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
The correct approach to avoiding such issues is simply
to make both aspects Wayland (extension) protocols, so
that Wayland color management and color sensitive applications
have the potential to work across all Wayland systems,
rather than being at best balkanized, or at worst, not
supported.
"not supported" == sRGB (gamma).
No, not supported = native device response = not color managed.
Post by Carsten Haitzler (The Rasterman)
render appropriately.
most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
I've no idea what you mean.
Post by Carsten Haitzler (The Rasterman)
either compositor will fake it and reduce your colors down to sRGB, or your
apps produce sRGB by default and have code paths for extended colorspace
support *IF* it exists AND different colorspaces are natively supported by the
display hardware.
No compositor is involved. If the application doesn't know
the output display profile, then it can't do color management.

Graeme Gill.
Carsten Haitzler (The Rasterman)
2016-12-14 08:25:12 UTC
Permalink
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
Post by Graeme Gill
The correct approach to avoiding such issues is simply
to make both aspects Wayland (extension) protocols, so
that Wayland color management and color sensitive applications
have the potential to work across all Wayland systems,
rather than being at best balkanized, or at worst, not
supported.
"not supported" == sRGB (gamma).
No, not supported = native device response = not color managed.
and for most displays that is sRGB.
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
render appropriately.
most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
I've no idea what you mean.
most displays have "horrible color response". they are sRGB. they cannot
display a wider part of the color spectrum. some professional monitors/displays
can do this. eg 98% of abobe RGB for example.

either way monitors tend to have slightly different color reproduction and most
are "not that good" so basically sRGB. the compositor then is effectively
saying "unmanaged == sRGB, but it may really be anything so don't be fussy".
Post by Graeme Gill
Post by Carsten Haitzler (The Rasterman)
either compositor will fake it and reduce your colors down to sRGB, or your
apps produce sRGB by default and have code paths for extended colorspace
support *IF* it exists AND different colorspaces are natively supported by
the display hardware.
No compositor is involved. If the application doesn't know
the output display profile, then it can't do color management.
it can assume sRGB.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
Pekka Paalanen
2016-12-15 12:25:35 UTC
Permalink
On Mon, 12 Dec 2016 18:18:21 +1100
Post by Graeme Gill
2) Expecting color management applications to deal with
configuring the compositor in a platform dependent
way, is expecting far too much. I for one am not
about to add multiple platform dependent back
ends (multiple flavors of Linux, BSD's, Android,
etc.) to my tools to do this, and no other major
platform expects it (i.e. none of MSWindows, OS X
or X11 based systems have this requirement.)
Indeed.

Applications have no right to be configuring *anything* in a desktop
compositor.

Configuring the compositor is an action with global effects, and
therefore must be privileged. It is usually reserved for the desktop
environment's configuration utilities that the user will be using
manually.


Thanks,
pq
Niels Ole Salscheider
2016-12-21 00:44:31 UTC
Permalink
Yes, exactly. But these are things that do not use the "normal" wayland
protocols but are initiated by the compositor.
I'm not sure what you mean by that. Why should the compositor launch
applications ? The user should launch applications they want to
use in the normal fashion they launch applications!
In practice this will mean that a compositor will use LCMS / ArgyllCMS /
... and the corresponding tools to accomplish these goals. The compositor
might use them as libraries, or maybe have a private D-Bus interface for
them. But it will be the compositor that initiates any action.
Not going to happen. They are not libraries, they are full blown,
complex applications. And they can't use D-Bus, because Wayland
doesn't use D-Bus. Think of (a future) remote Wayland as a test case.
How does a the remote user calibrate, profile and install the
a profile at a remote display they are sitting at ?
To work anywhere a Wayland application works, they
need to be Wayland applications, using the Wayland protocol.
(And the user will rightfully want to be able to choose
which color management tools they use, not be locked into
whatever the compositor provides - if it provides anything
at all that is, something I rather doubt.)
Developers of compositors and CMS can (and probably should) standardize
such an interface
And that is exactly what I want to happen.
(for example a library API or a D-Bus interface).
Using different mechanisms for communication raises
a host of issues about support and coordination of
Wayland and color management actions.
But this is out of scope for the wayland protocol.
Why is that so, given that compositor at the end of the Wayland
protocol has the job of managing graphics hardware ?
Because wayland does not have protocols for configuration as others have
pointed out. There isn't even a protocol to change the screen resolution.
You can try to discuss this fundamental design decision but I do not expect it
to change.
Post by Niels Ole Salscheider
- You DO NOT know which parts of a surface are shown on which screen.
So that needs to be fixed for color aware applications to be able to
provide display colorspace values.
That will be rather difficult in general.
I simply don't understand why. Wayland already has some of that
information available, in a less precise way :- it has
enter and leave events when a surface starts overlapping
or ceases to overlap a scanout region of an output.
All that is needed is the region information to
go along with those events.
I understand that you cannot satisfy all requirements by having ONLY a
simple color conversion to output color space in the compositor.
But are there transformations from input to output color space that cannot
be expressed as a (complex) transformation from input to intermediate
space (by the application) and then another transformation from
intermediate to output color space? At least as long as the intermediate
color space does not clip any color values.
I really do not know the answer to that and I will trust you on this.
Yes. The ICC PCS mix-and-match model has some notable limitations -
in fact it verges on conceptually broken, because it's not possible
to do real gamut mapping because the source gamut is divorced from
the destination gamut when the transformations are created.
The PRMG approach is sort of a fudgy workaround, but can't solve
the problem. See
<http://www.argyllcms.com/doc/iccgamutmapping.html> for a discussion
that touches on this.
So if an application is content to use pre-computed ICC A2B and B2A
transforms, and put up with the limitations of mix-and-match
intent selection and operation (perhaps it is satisfied by
colorimetric with profile default clipping, or generalized
gamut compression), then this is perfectly fine, and covers
a lot of ground. But I don't think a color management
solution should prevent an application doing better than
this if it wishes to go to the trouble, nor do I think
that Wayland should have limitations that preceding systems
don't have. Doing better than this means constructing overall
device to device transforms (source space to display space) where it
can use real gamut mappings, and can compute
higher precision transforms by inverting the A2B table
of the output profile rather than using the lower precision
pre-computed B2A table, etc.
Ok, I understand the problem: For high quality perceptual gamut mapping you
need to know the input and the output gamut and the precomputed tables might
assume a wrong corresponding profile.

I can only see three solutions to that problem:
1) The compositor does all gamut mapping with a high quality.
2) The application does all the gamut mapping and provides a surface for each
output.
3) Device link profiles.

I think 1 would fit into the wayland design and would have the additional
benefit that all applications (not only professional ones) benefit from it.
The disadvantage would be that it adds complexity to the compositor and the
latter is responsible for good results: If a compositor has a bad CMM there is
not much the application can do about.

Solution 2 comes with an overhead and brings some problems when there is no
surface for a specific output (e. g. because it was just plugged in).
I'm not sure how easy it would be to make this work. Maybe someone else can
comment on this?

The result of solution 3 would be similar to solution 2 but it would avoid the
overhead. It would also be easier from a protocol perspective.

Maybe allowing the application to choose between 1 and 3 would be a good
idea...
Or maybe some detail of the
compositor CMM doesn't work properly (CMM's have differences
and bugs), so an ability to implement its own CMM
is highly desirable. On top of that, calibration and
profiling applications need to be able to set display
values to do their job. So all this adds up to some means
of passing color values unchanged (or perhaps with an application
determined device to device conversion, which could be set to null)
from the application to the display.
I sketched out two extensions. Please critique and/or refine and/or
contrast them with other alternatives
Apart from one thing you already have your core profile as far as the
wayland protocol is concerned.
You mean the display ICC profile ? How is that set though ?
The one thing missing from a wayland protocol perspective is that you do
not know which parts of the surface cover which screen. This is a design
decision and I do not expect that this will change. One reason is that
the answer is often not that simple (a region can be displayed on
multiple screens) or that the compositor might not even know in advance.
Yet that information exists.
What MIGHT be possible is that an application provides the complete
surface in all color spaces of all outputs so that the compositor can use
the parts it needs.
Yes, that's an interesting thought. Another thought that avoids
the application having to know the exact surface to output mapping
would be for the application to provide a device link for
each output (I'm currently thinking through the implications
of such an approach.) Both ideas have similar issues -
you really want the per output pixels or device links to
be provided by the application on demand - i.e. when a surface
first overlaps an output, so that it doesn't have to pre-compute
pixels or device links for all possible outputs, even if they
never get used. This has interactivity implications. I think
there are probably pragmatic answers to these types of problems,
it just comes down to whether they are acceptable or whether
there are better alternatives.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Graeme Gill
2016-12-21 03:36:17 UTC
Permalink
Niels Ole Salscheider wrote:

Hi,
Post by Niels Ole Salscheider
Why is that so, given that compositor at the end of the Wayland
protocol has the job of managing graphics hardware ?
Because wayland does not have protocols for configuration as others have
pointed out. There isn't even a protocol to change the screen resolution.
You can try to discuss this fundamental design decision but I do not expect it
to change.
I understand, but I then wonder where Wayland and it's
associated systems sit. Is this an architectural problem,
or is it that the required surrounding eco-systems
are too immature or non-standard ?
Post by Niels Ole Salscheider
Ok, I understand the problem: For high quality perceptual gamut mapping you
need to know the input and the output gamut and the precomputed tables might
assume a wrong corresponding profile.
Right. Having that capability somewhere, guarantees that there are
no artificial limits on algorithm or precision, and future proofing it.
Post by Niels Ole Salscheider
1) The compositor does all gamut mapping with a high quality.
2) The application does all the gamut mapping and provides a surface for each
output.
3) Device link profiles.
I think 1 would fit into the wayland design and would have the additional
benefit that all applications (not only professional ones) benefit from it.
The disadvantage would be that it adds complexity to the compositor and the
latter is responsible for good results: If a compositor has a bad CMM there is
not much the application can do about.
Implementing a standard ICC based CMM is pretty easy if you use lcms as
a base, and what it does is well understood and predictable.
Implementing something more than that is an open ended problem,
and I don't think any attempt should be made to codify it into a
standard system.
Post by Niels Ole Salscheider
Solution 2 comes with an overhead and brings some problems when there is no
surface for a specific output (e. g. because it was just plugged in).
I'm not sure how easy it would be to make this work. Maybe someone else can
comment on this?
The reaction seems negative. I suspect it can be achieved, but
there seems little prospect of such support being accepted
at the moment.
Post by Niels Ole Salscheider
Maybe allowing the application to choose between 1 and 3 would be a good
idea...
Here's where my current thinking is in terms 3):

* Allow each surface to have a (source) colorspace ICC profile
set for it. This invokes standard CMM link to create a transform.

* Allow each surface to have one device link ICC profile for each
output set for it. This would be used in preference to the source
device profile if it is set.

* An application could create and set a device link when
it notices a surface overlaps an output via the existing
event. The compositor would re-render a surface if
the applicable profile changes or is set.

Problems with this:

* Applications that wish to dictate the source to display
conversion have to work harder in creating the device links,
something they don't have to do on other systems.

* It may not be reasonable to ask Wayland and the compositor
to handle arbitrary number of color channel rasters and
transforms. If not, then the application has to work pretty
hard - pick an intermediate RGB colorspace to
render the incoming images to, then create a profiles/device
link from that working space to the output space.

* How future proof are ICC device links as a means of
conveying the desired transform ? What about HDR etc.
as a test case ?

This doesn't address any of the problems of supporting
calibration, profiling or color setup, nor how display
profiles are installed or read by applications.

Cheers,

Graeme Gill.
Continue reading on narkive:
Loading...