[RFC,wayland-protocols,1/1] unstable: add color management protocol

Submitted by Sebastian Wick on Feb. 14, 2019, 2:46 a.m.

Details

Message ID 20190214024621.6892-2-sebastian@sebastianwick.net
State New
Headers show
Series "Color Management Protocol" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Sebastian Wick Feb. 14, 2019, 2:46 a.m.
This protocol allows clients to attach a color space and rendering
intent to a wl_surface. It further allows the client to be informed
which color spaces a wl_surface was converted to on the last presented.

Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
---
 Makefile.am                                   |   1 +
 unstable/color-management/README              |   4 +
 .../color-management-unstable-v1.xml          | 183 ++++++++++++++++++
 3 files changed, 188 insertions(+)
 create mode 100644 unstable/color-management/README
 create mode 100644 unstable/color-management/color-management-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..80abc1d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,7 @@  unstable_protocols =								\
 	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
 	unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
 	unstable/primary-selection/primary-selection-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..140f1e9
--- /dev/null
+++ b/unstable/color-management/README
@@ -0,0 +1,4 @@ 
+Color management protocol
+
+Maintainers:
+Sebastian Wick <sebastian@sebastianwick.net>
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..1615fe6
--- /dev/null
+++ b/unstable/color-management/color-management-unstable-v1.xml
@@ -0,0 +1,183 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="color_management_unstable_v1">
+
+  <copyright>
+    Copyright © 2019 Sebastian Wick
+    Copyright © 2019 Erwin Burema
+
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+
+  <description summary="color management protocol">
+    This protocol provides the ability to specify the color space
+    of a wl_surface. If further enumerates the color spaces currently
+    in the system and allows to query feedback about which color spaces
+    a wl_surface was converted to on the last present.
+    The idea behind the feedback system is to allow the client to do color
+    conversion to a color space which will likely be used to show the surface
+    which allows the compositor to skip the color conversion step.
+  </description>
+
+  <interface name="zwp_color_manager_v1" version="1">
+    <description summary="color manager">
+      The color manager is a singleton global object that provides access
+      to outputs' color spaces, let's you create new color spaces and attach
+      a color space to surfaces.
+    </description>
+
+    <enum name="render_intent">
+      <description summary="render intent">
+        render intents
+      </description>
+      <entry name="absolute" value="1"/>
+      <entry name="relative" value="2"/>
+      <entry name="perceptual" value="3"/>
+      <entry name="saturation" value="4" />
+    </enum>
+
+    <enum name="well_known_color_space">
+      <description summary="well-known color spaces">
+        Well-known color spaces
+      </description>
+      <entry name="none" value="0" summary="no known color space" />
+      <entry name="sRGB" value="1" summary="sRGB color space" />
+      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
+      <entry name="DCI-3P" value="3" summary="DCI-3P" />
+      <entry name="rec2020" value="4" summary="rec2020" />
+      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)" />
+      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve (HDR)" />
+    </enum>
+
+    <enum name="error">
+      <description summary="fatal color manager errors">
+        These fatal protocol errors may be emitted in response to
+        illegal color management requests.
+      </description>
+      <entry name="invalid_icc_profile" value="0" summary="invalid ICC profile"/>
+    </enum>
+
+    <request name="set_color_space">
+      <description summary="set the color space of a surface">
+        Set the color space of a surface. The color space is double buffered,
+        and will be applied at the time wl_surface.commit of the corresponding
+        wl_surface is called.
+
+        The render intent gives the compositor a hint what to optimize for
+        in color space conversions.
+
+        If a surface has no color space set, sRGB and an arbitrary render
+        intent will be assumed.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
+      <arg name="render_intent" type="uint" enum="render_intent"/>
+    </request>
+
+    <request name="color_space_feedback">
+      <description summary="color space feedback">
+        Request color space feedback for the current content submission
+        on the given surface. This creates a new color_space_feedback
+        object, which will deliver the feedback information once. If
+        multiple color_space_feedback objects are created for the same
+        submission, they will all deliver the same information.
+
+        For details on what information is returned, see the
+        color_space_feedback interface.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="feedback" type="new_id" interface="zwp_color_space_feedback_v1"/>
+    </request>
+
+    <request name="color_space_from_icc">
+      <description summary="create a color space from an ICC profile">
+        Create a color space from an ICC profile. Only three channel
+        profiles are allowed.
+      </description>
+      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
+      <arg name="icc" type="fd"/>
+    </request>
+
+    <event name="color_space_added">
+      <description summary="color space added">
+        Send after binding or when a new color space is added to the system.
+      </description>
+      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
+    </event>
+  </interface>
+
+  <interface name="zwp_color_space_v1" version="1">
+    <description summary="a color space">
+      A color space can be attached to a wl_surface and sends
+      information like the ICC profile to let the client perform color
+      correction.
+    </description>
+
+    <event name="information">
+      <description summary="color space information">
+        Information describing the color space.
+
+        The icc argument contains a fd to the corresponding ICC profile.
+        well-known can be used to easily identify a color-space.
+
+        A color space can be associated with a wl_output.
+      </description>
+      <arg name="icc" type="fd"/>
+      <arg name="well-known" type="uint" enum="well_known_color_space"/>
+      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
+    </event>
+
+    <event name="removed">
+      <description summary="color space removed">
+        This event is sent when the color space is removed from the system.
+        When this event is received, the client must destroy the object.
+      </description>
+    </event>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the color space object">
+	      Destroy the color_space object.
+      </description>
+    </request>
+  </interface>
+
+  <interface name="zwp_color_space_feedback_v1" version="1">
+    <description summary="color space feedback">
+      The surface content was converted to a number of color spaces
+      on the last content update. They get listed in decreasing order
+      of importance by the converted event.
+      Once a color_space_feedback object has delivered a done
+      event it is automatically destroyed.
+    </description>
+
+    <event name="converted">
+      <description summary="color space conversion">
+        The surface was converted to a color space.
+      </description>
+      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
+    </event>
+
+    <event name="done">
+      <description summary="done listing color space conversions">
+        All color space conversion have been listed.
+      </description>
+    </event>
+  </interface>
+
+</protocol>

Comments

On Wed, Feb 13, 2019 at 7:55 PM Sebastian Wick
<sebastian@sebastianwick.net> wrote:


> +      <entry name="absolute" value="1"/>

I suggest ICC spec language.  'ICC-absolute colorimetric'

> +      <entry name="relative" value="2"/>

'media-relative colorimetric'


> +      <entry name="none" value="0" summary="no known color space" />

I think this is 'deviceRGB' although it could be 'unknown'.
Practically, it could only be unknown if the values aren't being
displayed or output anywhere. The instant RGB values are displayed
anywhere, the color space is knowable, therefore it's at least
deviceRGB. But unknown is also consistent with EXIF.

And 'color space' can be assumed.

> +      <entry name="sRGB" value="1" summary="sRGB color space" />

Summary probably should be 'sRGB IEC61966-2.1' and again 'color space'
can be assumed.

> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />

Summary probably should be 'Adobe RGB (1998)'

> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />

DCI-P3
But there are three, so it needs to be specific which one or define
all three. And there's a variant, which is 'Display P3' from Apple,
which starts out being defined with DCI-P3 D65 but uses a tone
response curve defined by the sRGB curve.


> +      <entry name="rec2020" value="4" summary="rec2020" />

Probably the summary should be 'ITU-R BT.2020 for UHDTV' same for below.

> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)" />
> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve (HDR)" />

It's reasonable to add 'ITU-R BT.709 for HDTV' or Rec. 709 since
that's used today still.


--
Chris Murphy
Hello Sebastian, 
My comments inline. 

Regards
Shashank
> -----Original Message-----

> From: wayland-devel [mailto:wayland-devel-bounces@lists.freedesktop.org] On

> Behalf Of Sebastian Wick

> Sent: Thursday, February 14, 2019 8:16 AM

> To: wayland-devel@lists.freedesktop.org

> Cc: Sebastian Wick <sebastian@sebastianwick.net>

> Subject: [RFC wayland-protocols 1/1] unstable: add color management protocol

> 

> This protocol allows clients to attach a color space and rendering intent to a

> wl_surface. It further allows the client to be informed which color spaces a wl_surface

> was converted to on the last presented.

> 

> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>

> ---

>  Makefile.am                                   |   1 +

>  unstable/color-management/README              |   4 +

>  .../color-management-unstable-v1.xml          | 183 ++++++++++++++++++

>  3 files changed, 188 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 345ae6a..80abc1d 100644

> --- a/Makefile.am

> +++ b/Makefile.am

> @@ -23,6 +23,7 @@ unstable_protocols =

> 		\

>  	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\

>  	unstable/linux-explicit-synchronization/linux-explicit-synchronization-

> unstable-v1.xml \

>  	unstable/primary-selection/primary-selection-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..140f1e9

> --- /dev/null

> +++ b/unstable/color-management/README

> @@ -0,0 +1,4 @@

> +Color management protocol

> +

> +Maintainers:

> +Sebastian Wick <sebastian@sebastianwick.net>

> 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..1615fe6

> --- /dev/null

> +++ b/unstable/color-management/color-management-unstable-v1.xml

> @@ -0,0 +1,183 @@

> +<?xml version="1.0" encoding="UTF-8"?>

> +<protocol name="color_management_unstable_v1">

> +

> +  <copyright>

> +    Copyright © 2019 Sebastian Wick

> +    Copyright © 2019 Erwin Burema

> +

> +    Permission is hereby granted, free of charge, to any person obtaining a

> +    copy of this software and associated documentation files (the "Software"),

> +    to deal in the Software without restriction, including without limitation

> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,

> +    and/or sell copies of the Software, and to permit persons to whom the

> +    Software is furnished to do so, subject to the following conditions:

> +

> +    The above copyright notice and this permission notice (including the next

> +    paragraph) shall be included in all copies or substantial portions of the

> +    Software.

> +

> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

> EXPRESS OR

> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

> MERCHANTABILITY,

> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT

> SHALL

> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES

> OR OTHER

> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,

> ARISING

> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR

> OTHER

> +    DEALINGS IN THE SOFTWARE.

> +  </copyright>

> +

> +  <description summary="color management protocol">

> +    This protocol provides the ability to specify the color space

> +    of a wl_surface. If further enumerates the color spaces currently

> +    in the system and allows to query feedback about which color spaces

> +    a wl_surface was converted to on the last present.

> +    The idea behind the feedback system is to allow the client to do color

> +    conversion to a color space which will likely be used to show the surface

> +    which allows the compositor to skip the color conversion step.

> +  </description>

> +

> +  <interface name="zwp_color_manager_v1" version="1">

> +    <description summary="color manager">

> +      The color manager is a singleton global object that provides access

> +      to outputs' color spaces, let's you create new color spaces and attach

> +      a color space to surfaces.

> +    </description>

> +

> +    <enum name="render_intent">

> +      <description summary="render intent">

> +        render intents

> +      </description>

> +      <entry name="absolute" value="1"/>

> +      <entry name="relative" value="2"/>

> +      <entry name="perceptual" value="3"/>

> +      <entry name="saturation" value="4" />

Would you elaborate a bit more on what do we want to achieve with render-intent ? How can the compositor utilize this filed during color conversion ? 
> +    </enum>

> +

> +    <enum name="well_known_color_space">

> +      <description summary="well-known color spaces">

Its slightly difficult to define what is the definition of a "well-known" color space, as different use cases may have their own favorite. May be we can call it "general-purpose" or "standard" or something in those line. 
> +        Well-known color spaces

> +      </description>

> +      <entry name="none" value="0" summary="no known color space" />

> +      <entry name="sRGB" value="1" summary="sRGB color space" />

> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />

> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />

I guess we mean DCI-P3 here
> +      <entry name="rec2020" value="4" summary="rec2020" />

> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)"

> />

> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve

> (HDR)" />

Well, this is slightly off the chart for me. If I understood this correctly, the cover letter talks about the intent is to focus on Colorspace only, but here we are differentiating enum values based on their EOTF HDR curve, which is the only difference between these three colorspaces. Then why not just mind the colorspace regardless of the HDR curve. 

On the other hand, we can accommodate the HDR specific information also, like the EOTF curve type, and the HDR metadata type and content for the frame, if we can add some additional filed in this same protocol. So the colorspace information will remain the same, and the presence of HDR metadata type / content filed can indicate if the current frame is HDR BT2020 frame or SDR BT2020 frame. 

Ankit from my team, has something similar being implemented to address the color management and HDR requirements in the same protocol. May be you guys can merge your solutions and come-up with something even more  exiting and usable. 
> +    </enum>

> +

> +    <enum name="error">

> +      <description summary="fatal color manager errors">

> +        These fatal protocol errors may be emitted in response to

> +        illegal color management requests.

> +      </description>

> +      <entry name="invalid_icc_profile" value="0" summary="invalid ICC profile"/>

> +    </enum>

> +

> +    <request name="set_color_space">

> +      <description summary="set the color space of a surface">

> +        Set the color space of a surface. The color space is double buffered,

> +        and will be applied at the time wl_surface.commit of the corresponding

> +        wl_surface is called.

> +

> +        The render intent gives the compositor a hint what to optimize for

> +        in color space conversions.

> +

> +        If a surface has no color space set, sRGB and an arbitrary render

> +        intent will be assumed.

> +      </description>

> +      <arg name="surface" type="object" interface="wl_surface"/>

> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>

> +      <arg name="render_intent" type="uint" enum="render_intent"/>

> +    </request>

> +

> +    <request name="color_space_feedback">

> +      <description summary="color space feedback">

> +        Request color space feedback for the current content submission

> +        on the given surface. This creates a new color_space_feedback

> +        object, which will deliver the feedback information once. If

> +        multiple color_space_feedback objects are created for the same

> +        submission, they will all deliver the same information.

> +

> +        For details on what information is returned, see the

> +        color_space_feedback interface.

> +      </description>

> +      <arg name="surface" type="object" interface="wl_surface"/>

> +      <arg name="feedback" type="new_id"

> interface="zwp_color_space_feedback_v1"/>

> +    </request>

> +

> +    <request name="color_space_from_icc">

> +      <description summary="create a color space from an ICC profile">

> +        Create a color space from an ICC profile. Only three channel

> +        profiles are allowed.

> +      </description>

> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>

> +      <arg name="icc" type="fd"/>

> +    </request>

> +

> +    <event name="color_space_added">

> +      <description summary="color space added">

> +        Send after binding or when a new color space is added to the system.

> +      </description>

> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>

> +    </event>

> +  </interface>

> +

> +  <interface name="zwp_color_space_v1" version="1">

> +    <description summary="a color space">

> +      A color space can be attached to a wl_surface and sends

> +      information like the ICC profile to let the client perform color

> +      correction.

> +    </description>

> +

> +    <event name="information">

> +      <description summary="color space information">

> +        Information describing the color space.

> +

> +        The icc argument contains a fd to the corresponding ICC profile.

> +        well-known can be used to easily identify a color-space.

> +

> +        A color space can be associated with a wl_output.

> +      </description>

> +      <arg name="icc" type="fd"/>

> +      <arg name="well-known" type="uint" enum="well_known_color_space"/>

> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>

> +    </event>

> +

> +    <event name="removed">

> +      <description summary="color space removed">

> +        This event is sent when the color space is removed from the system.

> +        When this event is received, the client must destroy the object.

> +      </description>

> +    </event>

> +

> +    <request name="destroy" type="destructor">

> +      <description summary="destroy the color space object">

> +	      Destroy the color_space object.

> +      </description>

> +    </request>

> +  </interface>

> +

> +  <interface name="zwp_color_space_feedback_v1" version="1">

> +    <description summary="color space feedback">

> +      The surface content was converted to a number of color spaces

> +      on the last content update. They get listed in decreasing order

> +      of importance by the converted event.

> +      Once a color_space_feedback object has delivered a done

> +      event it is automatically destroyed.

> +    </description>

> +

> +    <event name="converted">

> +      <description summary="color space conversion">

> +        The surface was converted to a color space.

> +      </description>

> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>

> +    </event>

> +

> +    <event name="done">

> +      <description summary="done listing color space conversions">

> +        All color space conversion have been listed.

> +      </description>

> +    </event>

> +  </interface>

> +

> +</protocol>

> --

> 2.20.1

> 

> _______________________________________________

> wayland-devel mailing list

> wayland-devel@lists.freedesktop.org

> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Thanks. I don't really know about all the standards so I'll just trust 
you on this.

On 2019-02-14 05:47, Chris Murphy wrote:
> On Wed, Feb 13, 2019 at 7:55 PM Sebastian Wick
> <sebastian@sebastianwick.net> wrote:
> 
> 
>> +      <entry name="absolute" value="1"/>
> 
> I suggest ICC spec language.  'ICC-absolute colorimetric'
> 
>> +      <entry name="relative" value="2"/>
> 
> 'media-relative colorimetric'
> 
> 
>> +      <entry name="none" value="0" summary="no known color space" />
> 
> I think this is 'deviceRGB' although it could be 'unknown'.
> Practically, it could only be unknown if the values aren't being
> displayed or output anywhere. The instant RGB values are displayed
> anywhere, the color space is knowable, therefore it's at least
> deviceRGB. But unknown is also consistent with EXIF.
> 
> And 'color space' can be assumed.
> 
>> +      <entry name="sRGB" value="1" summary="sRGB color space" />
> 
> Summary probably should be 'sRGB IEC61966-2.1' and again 'color space'
> can be assumed.
> 
>> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> 
> Summary probably should be 'Adobe RGB (1998)'
> 
>> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> 
> DCI-P3
> But there are three, so it needs to be specific which one or define
> all three. And there's a variant, which is 'Display P3' from Apple,
> which starts out being defined with DCI-P3 D65 but uses a tone
> response curve defined by the sRGB curve.
> 
> 
>> +      <entry name="rec2020" value="4" summary="rec2020" />
> 
> Probably the summary should be 'ITU-R BT.2020 for UHDTV' same for 
> below.
> 
>> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq 
>> curve (HDR)" />
>> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG 
>> curve (HDR)" />
> 
> It's reasonable to add 'ITU-R BT.709 for HDTV' or Rec. 709 since
> that's used today still.
> 
> 
> --
> Chris Murphy
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 2019-02-14 05:55, Sharma, Shashank via wayland-devel wrote:
> Hello Sebastian,
> My comments inline.
> 
> Regards
> Shashank
>> -----Original Message-----
>> From: wayland-devel 
>> [mailto:wayland-devel-bounces@lists.freedesktop.org] On
>> Behalf Of Sebastian Wick
>> Sent: Thursday, February 14, 2019 8:16 AM
>> To: wayland-devel@lists.freedesktop.org
>> Cc: Sebastian Wick <sebastian@sebastianwick.net>
>> Subject: [RFC wayland-protocols 1/1] unstable: add color management 
>> protocol
>> 
>> This protocol allows clients to attach a color space and rendering 
>> intent to a
>> wl_surface. It further allows the client to be informed which color 
>> spaces a wl_surface
>> was converted to on the last presented.
>> 
>> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
>> ---
>>  Makefile.am                                   |   1 +
>>  unstable/color-management/README              |   4 +
>>  .../color-management-unstable-v1.xml          | 183 
>> ++++++++++++++++++
>>  3 files changed, 188 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 345ae6a..80abc1d 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -23,6 +23,7 @@ unstable_protocols =
>> 		\
>>  	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
>>  
>> 	unstable/linux-explicit-synchronization/linux-explicit-synchronization-
>> unstable-v1.xml \
>>  	unstable/primary-selection/primary-selection-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..140f1e9
>> --- /dev/null
>> +++ b/unstable/color-management/README
>> @@ -0,0 +1,4 @@
>> +Color management protocol
>> +
>> +Maintainers:
>> +Sebastian Wick <sebastian@sebastianwick.net>
>> 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..1615fe6
>> --- /dev/null
>> +++ b/unstable/color-management/color-management-unstable-v1.xml
>> @@ -0,0 +1,183 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<protocol name="color_management_unstable_v1">
>> +
>> +  <copyright>
>> +    Copyright © 2019 Sebastian Wick
>> +    Copyright © 2019 Erwin Burema
>> +
>> +    Permission is hereby granted, free of charge, to any person 
>> obtaining a
>> +    copy of this software and associated documentation files (the 
>> "Software"),
>> +    to deal in the Software without restriction, including without 
>> limitation
>> +    the rights to use, copy, modify, merge, publish, distribute, 
>> sublicense,
>> +    and/or sell copies of the Software, and to permit persons to whom 
>> the
>> +    Software is furnished to do so, subject to the following 
>> conditions:
>> +
>> +    The above copyright notice and this permission notice (including 
>> the next
>> +    paragraph) shall be included in all copies or substantial 
>> portions of the
>> +    Software.
>> +
>> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 
>> EVENT
>> SHALL
>> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
>> OR OTHER
>> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING
>> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> OTHER
>> +    DEALINGS IN THE SOFTWARE.
>> +  </copyright>
>> +
>> +  <description summary="color management protocol">
>> +    This protocol provides the ability to specify the color space
>> +    of a wl_surface. If further enumerates the color spaces currently
>> +    in the system and allows to query feedback about which color 
>> spaces
>> +    a wl_surface was converted to on the last present.
>> +    The idea behind the feedback system is to allow the client to do 
>> color
>> +    conversion to a color space which will likely be used to show the 
>> surface
>> +    which allows the compositor to skip the color conversion step.
>> +  </description>
>> +
>> +  <interface name="zwp_color_manager_v1" version="1">
>> +    <description summary="color manager">
>> +      The color manager is a singleton global object that provides 
>> access
>> +      to outputs' color spaces, let's you create new color spaces and 
>> attach
>> +      a color space to surfaces.
>> +    </description>
>> +
>> +    <enum name="render_intent">
>> +      <description summary="render intent">
>> +        render intents
>> +      </description>
>> +      <entry name="absolute" value="1"/>
>> +      <entry name="relative" value="2"/>
>> +      <entry name="perceptual" value="3"/>
>> +      <entry name="saturation" value="4" />
> Would you elaborate a bit more on what do we want to achieve with
> render-intent ? How can the compositor utilize this filed during color
> conversion ?

It's about how to handle colors which are outside of the destionation 
gamut
https://en.wikipedia.org/wiki/Color_management#Rendering_intent

>> +    </enum>
>> +
>> +    <enum name="well_known_color_space">
>> +      <description summary="well-known color spaces">
> Its slightly difficult to define what is the definition of a
> "well-known" color space, as different use cases may have their own
> favorite. May be we can call it "general-purpose" or "standard" or
> something in those line.
>> +        Well-known color spaces
>> +      </description>
>> +      <entry name="none" value="0" summary="no known color space" />
>> +      <entry name="sRGB" value="1" summary="sRGB color space" />
>> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
>> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> I guess we mean DCI-P3 here
>> +      <entry name="rec2020" value="4" summary="rec2020" />
>> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq 
>> curve (HDR)"
>> />
>> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG 
>> curve
>> (HDR)" />
> Well, this is slightly off the chart for me. If I understood this
> correctly, the cover letter talks about the intent is to focus on
> Colorspace only, but here we are differentiating enum values based on
> their EOTF HDR curve, which is the only difference between these three
> colorspaces. Then why not just mind the colorspace regardless of the
> HDR curve.

A color space consits of three primaries, the white point and the 
EOTF/OETF.
Just because two color spaces share the same color gamut doesn't mean 
that
they're the same. You're right though that a conversion between those 
color
spaces would not require a render intent but since we don't know which 
color
spaces we end up having to convert to we need a render intent always.

The point of the enum is to give some ICCs a recognizable name so 
clients have
the ability to identify those color spaces without having to poke the 
ICC
profile.

> 
> On the other hand, we can accommodate the HDR specific information
> also, like the EOTF curve type, and the HDR metadata type and content
> for the frame, if we can add some additional filed in this same
> protocol. So the colorspace information will remain the same, and the
> presence of HDR metadata type / content filed can indicate if the
> current frame is HDR BT2020 frame or SDR BT2020 frame.

This is where my lack of knowledge about HDR standards might become a
problem. My understanding right now is that the HDR standards define a 
color
space (which includes EOTF) and then has (potentially dynamic) metadata 
which
specifies the luminance.

If my understanding is correct a request which sets the HDR metadata 
would be
sufficient. Another request to set a custom tone curve would be highly 
useful,
too.

> 
> Ankit from my team, has something similar being implemented to address
> the color management and HDR requirements in the same protocol. May be
> you guys can merge your solutions and come-up with something even more
>  exiting and usable.

I'd love to hear more about that. Feel free to contact me on IRC 
(swick), mail
or just on this list.

>> +    </enum>
>> +
>> +    <enum name="error">
>> +      <description summary="fatal color manager errors">
>> +        These fatal protocol errors may be emitted in response to
>> +        illegal color management requests.
>> +      </description>
>> +      <entry name="invalid_icc_profile" value="0" summary="invalid 
>> ICC profile"/>
>> +    </enum>
>> +
>> +    <request name="set_color_space">
>> +      <description summary="set the color space of a surface">
>> +        Set the color space of a surface. The color space is double 
>> buffered,
>> +        and will be applied at the time wl_surface.commit of the 
>> corresponding
>> +        wl_surface is called.
>> +
>> +        The render intent gives the compositor a hint what to 
>> optimize for
>> +        in color space conversions.
>> +
>> +        If a surface has no color space set, sRGB and an arbitrary 
>> render
>> +        intent will be assumed.
>> +      </description>
>> +      <arg name="surface" type="object" interface="wl_surface"/>
>> +      <arg name="color_space" type="object" 
>> interface="zwp_color_space_v1"/>
>> +      <arg name="render_intent" type="uint" enum="render_intent"/>
>> +    </request>
>> +
>> +    <request name="color_space_feedback">
>> +      <description summary="color space feedback">
>> +        Request color space feedback for the current content 
>> submission
>> +        on the given surface. This creates a new color_space_feedback
>> +        object, which will deliver the feedback information once. If
>> +        multiple color_space_feedback objects are created for the 
>> same
>> +        submission, they will all deliver the same information.
>> +
>> +        For details on what information is returned, see the
>> +        color_space_feedback interface.
>> +      </description>
>> +      <arg name="surface" type="object" interface="wl_surface"/>
>> +      <arg name="feedback" type="new_id"
>> interface="zwp_color_space_feedback_v1"/>
>> +    </request>
>> +
>> +    <request name="color_space_from_icc">
>> +      <description summary="create a color space from an ICC 
>> profile">
>> +        Create a color space from an ICC profile. Only three channel
>> +        profiles are allowed.
>> +      </description>
>> +      <arg name="color_space" type="new_id" 
>> interface="zwp_color_space_v1"/>
>> +      <arg name="icc" type="fd"/>
>> +    </request>
>> +
>> +    <event name="color_space_added">
>> +      <description summary="color space added">
>> +        Send after binding or when a new color space is added to the 
>> system.
>> +      </description>
>> +      <arg name="color_space" type="new_id" 
>> interface="zwp_color_space_v1"/>
>> +    </event>
>> +  </interface>
>> +
>> +  <interface name="zwp_color_space_v1" version="1">
>> +    <description summary="a color space">
>> +      A color space can be attached to a wl_surface and sends
>> +      information like the ICC profile to let the client perform 
>> color
>> +      correction.
>> +    </description>
>> +
>> +    <event name="information">
>> +      <description summary="color space information">
>> +        Information describing the color space.
>> +
>> +        The icc argument contains a fd to the corresponding ICC 
>> profile.
>> +        well-known can be used to easily identify a color-space.
>> +
>> +        A color space can be associated with a wl_output.
>> +      </description>
>> +      <arg name="icc" type="fd"/>
>> +      <arg name="well-known" type="uint" 
>> enum="well_known_color_space"/>
>> +      <arg name="output" type="object" interface="wl_output" 
>> allow-null="true"/>
>> +    </event>
>> +
>> +    <event name="removed">
>> +      <description summary="color space removed">
>> +        This event is sent when the color space is removed from the 
>> system.
>> +        When this event is received, the client must destroy the 
>> object.
>> +      </description>
>> +    </event>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="destroy the color space object">
>> +	      Destroy the color_space object.
>> +      </description>
>> +    </request>
>> +  </interface>
>> +
>> +  <interface name="zwp_color_space_feedback_v1" version="1">
>> +    <description summary="color space feedback">
>> +      The surface content was converted to a number of color spaces
>> +      on the last content update. They get listed in decreasing order
>> +      of importance by the converted event.
>> +      Once a color_space_feedback object has delivered a done
>> +      event it is automatically destroyed.
>> +    </description>
>> +
>> +    <event name="converted">
>> +      <description summary="color space conversion">
>> +        The surface was converted to a color space.
>> +      </description>
>> +      <arg name="color_space" type="object" 
>> interface="zwp_color_space_v1"/>
>> +    </event>
>> +
>> +    <event name="done">
>> +      <description summary="done listing color space conversions">
>> +        All color space conversion have been listed.
>> +      </description>
>> +    </event>
>> +  </interface>
>> +
>> +</protocol>
>> --
>> 2.20.1
>> 
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi Sebastian,

I am trying to extend Ole's color management protocol [1] to enable a 
client to pass HDR meta data.
Added the modified protocol as weston protocol for the time being. [2]

You have mention that the proposed protocol, ignores the HDR 
calibration/profiling,  so do you suggest there should
be another protocol for that altogether or is there a possibility to 
extend this for handling HDR metadata?

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html
[2] 
https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c

Also, there are a few queries to understand the flow, please find below 
inline:


On 2/14/2019 8:16 AM, Sebastian Wick wrote:
> This protocol allows clients to attach a color space and rendering
> intent to a wl_surface. It further allows the client to be informed
> which color spaces a wl_surface was converted to on the last presented.
>
> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
> ---
>   Makefile.am                                   |   1 +
>   unstable/color-management/README              |   4 +
>   .../color-management-unstable-v1.xml          | 183 ++++++++++++++++++
>   3 files changed, 188 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 345ae6a..80abc1d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,6 +23,7 @@ unstable_protocols =								\
>   	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
>   	unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
>   	unstable/primary-selection/primary-selection-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..140f1e9
> --- /dev/null
> +++ b/unstable/color-management/README
> @@ -0,0 +1,4 @@
> +Color management protocol
> +
> +Maintainers:
> +Sebastian Wick <sebastian@sebastianwick.net>
> 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..1615fe6
> --- /dev/null
> +++ b/unstable/color-management/color-management-unstable-v1.xml
> @@ -0,0 +1,183 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="color_management_unstable_v1">
> +
> +  <copyright>
> +    Copyright © 2019 Sebastian Wick
> +    Copyright © 2019 Erwin Burema
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <description summary="color management protocol">
> +    This protocol provides the ability to specify the color space
> +    of a wl_surface. If further enumerates the color spaces currently
> +    in the system and allows to query feedback about which color spaces
> +    a wl_surface was converted to on the last present.
> +    The idea behind the feedback system is to allow the client to do color
> +    conversion to a color space which will likely be used to show the surface
> +    which allows the compositor to skip the color conversion step.
> +  </description>
> +
> +  <interface name="zwp_color_manager_v1" version="1">
> +    <description summary="color manager">
> +      The color manager is a singleton global object that provides access
> +      to outputs' color spaces, let's you create new color spaces and attach
> +      a color space to surfaces.
> +    </description>
> +
> +    <enum name="render_intent">
> +      <description summary="render intent">
> +        render intents
> +      </description>
> +      <entry name="absolute" value="1"/>
> +      <entry name="relative" value="2"/>
> +      <entry name="perceptual" value="3"/>
> +      <entry name="saturation" value="4" />
> +    </enum>
> +
> +    <enum name="well_known_color_space">
> +      <description summary="well-known color spaces">
> +        Well-known color spaces
> +      </description>
> +      <entry name="none" value="0" summary="no known color space" />
> +      <entry name="sRGB" value="1" summary="sRGB color space" />
> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> +      <entry name="rec2020" value="4" summary="rec2020" />
> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)" />
> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve (HDR)" />
> +    </enum>
> +
> +    <enum name="error">
> +      <description summary="fatal color manager errors">
> +        These fatal protocol errors may be emitted in response to
> +        illegal color management requests.
> +      </description>
> +      <entry name="invalid_icc_profile" value="0" summary="invalid ICC profile"/>
> +    </enum>
> +
> +    <request name="set_color_space">
> +      <description summary="set the color space of a surface">
> +        Set the color space of a surface. The color space is double buffered,
> +        and will be applied at the time wl_surface.commit of the corresponding
> +        wl_surface is called.
> +
> +        The render intent gives the compositor a hint what to optimize for
> +        in color space conversions.
> +
> +        If a surface has no color space set, sRGB and an arbitrary render
> +        intent will be assumed.
> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
> +      <arg name="render_intent" type="uint" enum="render_intent"/>
> +    </request>
> +
> +    <request name="color_space_feedback">
> +      <description summary="color space feedback">
> +        Request color space feedback for the current content submission
> +        on the given surface. This creates a new color_space_feedback
> +        object, which will deliver the feedback information once. If
> +        multiple color_space_feedback objects are created for the same
> +        submission, they will all deliver the same information.
> +
> +        For details on what information is returned, see the
> +        color_space_feedback interface.
> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="feedback" type="new_id" interface="zwp_color_space_feedback_v1"/>
> +    </request>
> +
> +    <request name="color_space_from_icc">
> +      <description summary="create a color space from an ICC profile">
> +        Create a color space from an ICC profile. Only three channel
> +        profiles are allowed.
> +      </description>
> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
> +      <arg name="icc" type="fd"/>
> +    </request>
> +

If I understand it correctly,
the client first sends a request for getting color-space for an icc 
file, receives the color_space interface.
If we can add the surface in this requests, it can be tied to the 
color-space interface, and later set color_space,
without the surface.

You have declared some of the color-space as well known, do you think it 
will be useful to also let the
client get the color_space interface, based on the well-known color-space.?
Server on the other hand can have already built objects from the 
standard icc files, the interfaces of
which can be passed to the client.

> +    <event name="color_space_added">
> +      <description summary="color space added">
> +        Send after binding or when a new color space is added to the system.
> +      </description>
> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
> +    </event>
> +  </interface>
> +
> +  <interface name="zwp_color_space_v1" version="1">
> +    <description summary="a color space">
> +      A color space can be attached to a wl_surface and sends
> +      information like the ICC profile to let the client perform color
> +      correction.
> +    </description>
> +
> +    <event name="information">
> +      <description summary="color space information">
> +        Information describing the color space.
> +
> +        The icc argument contains a fd to the corresponding ICC profile.
> +        well-known can be used to easily identify a color-space.
> +
> +        A color space can be associated with a wl_output.
> +      </description>
> +      <arg name="icc" type="fd"/>
> +      <arg name="well-known" type="uint" enum="well_known_color_space"/>
> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
> +    </event>
> +

When will this event be generated, should there be a request from a 
client via the color_space interface
for the information? Will events be sent for each output, the surface is 
displayed on?

> +    <event name="removed">
> +      <description summary="color space removed">
> +        This event is sent when the color space is removed from the system.
> +        When this event is received, the client must destroy the object.
> +      </description>
> +    </event>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the color space object">
> +	      Destroy the color_space object.
> +      </description>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_color_space_feedback_v1" version="1">
> +    <description summary="color space feedback">
> +      The surface content was converted to a number of color spaces
> +      on the last content update. They get listed in decreasing order
> +      of importance by the converted event.
> +      Once a color_space_feedback object has delivered a done
> +      event it is automatically destroyed.
> +    </description>
> +
> +    <event name="converted">
> +      <description summary="color space conversion">
> +        The surface was converted to a color space.
> +      </description>
> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
> +    </event>
> +

So a client with a surface, will receive a series of these events for 
its surface, whenever the
color space conversion takes place for that surface?
Why do we need this interface, can the color_manager be used to send 
these events?

Thanks & Regards,
Ankit
> +    <event name="done">
> +      <description summary="done listing color space conversions">
> +        All color space conversion have been listed.
> +      </description>
> +    </event>
> +  </interface>
> +
> +</protocol>
On 2019-02-14 08:13, Nautiyal, Ankit K via wayland-devel wrote:
> Hi Sebastian,
> 
> I am trying to extend Ole's color management protocol [1] to enable a
> client to pass HDR meta data.
> Added the modified protocol as weston protocol for the time being. [2]

Thanks. That's useful.

> 
> You have mention that the proposed protocol, ignores the HDR
> calibration/profiling,  so do you suggest there should
> be another protocol for that altogether or is there a possibility to
> extend this for handling HDR metadata?

I absolutely think that this can be extended for handling HDR.

> 
> [1]
> https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html
> [2]
> https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c
> 
> Also, there are a few queries to understand the flow, please find
> below inline:
> On 2/14/2019 8:16 AM, Sebastian Wick wrote:
> 
>> This protocol allows clients to attach a color space and rendering
>> intent to a wl_surface. It further allows the client to be informed
>> which color spaces a wl_surface was converted to on the last
>> presented.
>> 
>> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
>> ---
>> Makefile.am                                   |   1 +
>> unstable/color-management/README              |   4 +
>> .../color-management-unstable-v1.xml          | 183
>> ++++++++++++++++++
>> 3 files changed, 188 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 345ae6a..80abc1d 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -23,6 +23,7 @@ unstable_protocols =
>> \
>> unstable/xdg-decoration/xdg-decoration-unstable-v1.xml    \
>> 
>> 
> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
>> \
>> unstable/primary-selection/primary-selection-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..140f1e9
>> --- /dev/null
>> +++ b/unstable/color-management/README
>> @@ -0,0 +1,4 @@
>> +Color management protocol
>> +
>> +Maintainers:
>> +Sebastian Wick <sebastian@sebastianwick.net>
>> 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..1615fe6
>> --- /dev/null
>> +++ b/unstable/color-management/color-management-unstable-v1.xml
>> @@ -0,0 +1,183 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<protocol name="color_management_unstable_v1">
>> +
>> +  <copyright>
>> +    Copyright © 2019 Sebastian Wick
>> +    Copyright © 2019 Erwin Burema
>> +
>> +    Permission is hereby granted, free of charge, to any person
>> obtaining a
>> +    copy of this software and associated documentation files (the
>> "Software"),
>> +    to deal in the Software without restriction, including without
>> limitation
>> +    the rights to use, copy, modify, merge, publish, distribute,
>> sublicense,
>> +    and/or sell copies of the Software, and to permit persons to
>> whom the
>> +    Software is furnished to do so, subject to the following
>> conditions:
>> +
>> +    The above copyright notice and this permission notice
>> (including the next
>> +    paragraph) shall be included in all copies or substantial
>> portions of the
>> +    Software.
>> +
>> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
>> EVENT SHALL
>> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
>> DAMAGES OR OTHER
>> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING
>> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> OTHER
>> +    DEALINGS IN THE SOFTWARE.
>> +  </copyright>
>> +
>> +  <description summary="color management protocol">
>> +    This protocol provides the ability to specify the color space
>> +    of a wl_surface. If further enumerates the color spaces
>> currently
>> +    in the system and allows to query feedback about which color
>> spaces
>> +    a wl_surface was converted to on the last present.
>> +    The idea behind the feedback system is to allow the client to
>> do color
>> +    conversion to a color space which will likely be used to show
>> the surface
>> +    which allows the compositor to skip the color conversion step.
>> +  </description>
>> +
>> +  <interface name="zwp_color_manager_v1" version="1">
>> +    <description summary="color manager">
>> +      The color manager is a singleton global object that provides
>> access
>> +      to outputs' color spaces, let's you create new color spaces
>> and attach
>> +      a color space to surfaces.
>> +    </description>
>> +
>> +    <enum name="render_intent">
>> +      <description summary="render intent">
>> +        render intents
>> +      </description>
>> +      <entry name="absolute" value="1"/>
>> +      <entry name="relative" value="2"/>
>> +      <entry name="perceptual" value="3"/>
>> +      <entry name="saturation" value="4" />
>> +    </enum>
>> +
>> +    <enum name="well_known_color_space">
>> +      <description summary="well-known color spaces">
>> +        Well-known color spaces
>> +      </description>
>> +      <entry name="none" value="0" summary="no known color space"
>> />
>> +      <entry name="sRGB" value="1" summary="sRGB color space" />
>> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
>> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
>> +      <entry name="rec2020" value="4" summary="rec2020" />
>> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq
>> curve (HDR)" />
>> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG
>> curve (HDR)" />
>> +    </enum>
>> +
>> +    <enum name="error">
>> +      <description summary="fatal color manager errors">
>> +        These fatal protocol errors may be emitted in response to
>> +        illegal color management requests.
>> +      </description>
>> +      <entry name="invalid_icc_profile" value="0" summary="invalid
>> ICC profile"/>
>> +    </enum>
>> +
>> +    <request name="set_color_space">
>> +      <description summary="set the color space of a surface">
>> +        Set the color space of a surface. The color space is double
>> buffered,
>> +        and will be applied at the time wl_surface.commit of the
>> corresponding
>> +        wl_surface is called.
>> +
>> +        The render intent gives the compositor a hint what to
>> optimize for
>> +        in color space conversions.
>> +
>> +        If a surface has no color space set, sRGB and an arbitrary
>> render
>> +        intent will be assumed.
>> +      </description>
>> +      <arg name="surface" type="object" interface="wl_surface"/>
>> +      <arg name="color_space" type="object"
>> interface="zwp_color_space_v1"/>
>> +      <arg name="render_intent" type="uint" enum="render_intent"/>
>> +    </request>
>> +
>> +    <request name="color_space_feedback">
>> +      <description summary="color space feedback">
>> +        Request color space feedback for the current content
>> submission
>> +        on the given surface. This creates a new
>> color_space_feedback
>> +        object, which will deliver the feedback information once.
>> If
>> +        multiple color_space_feedback objects are created for the
>> same
>> +        submission, they will all deliver the same information.
>> +
>> +        For details on what information is returned, see the
>> +        color_space_feedback interface.
>> +      </description>
>> +      <arg name="surface" type="object" interface="wl_surface"/>
>> +      <arg name="feedback" type="new_id"
>> interface="zwp_color_space_feedback_v1"/>
>> +    </request>
>> +
>> +    <request name="color_space_from_icc">
>> +      <description summary="create a color space from an ICC
>> profile">
>> +        Create a color space from an ICC profile. Only three
>> channel
>> +        profiles are allowed.
>> +      </description>
>> +      <arg name="color_space" type="new_id"
>> interface="zwp_color_space_v1"/>
>> +      <arg name="icc" type="fd"/>
>> +    </request>
>> +
> 
> If I understand it correctly,
> the client first sends a request for getting color-space for an icc
> file, receives the color_space interface.
> If we can add the surface in this requests, it can be tied to the
> color-space interface, and later set color_space,
> without the surface.

There is two ways to get a color_space object. The first one is to 
listen for
color_space_added events and the other, like you noted, is to call
color_space_from_icc.
However, I don't see why a color space should should be tied to a 
wl_surface
from the beginning. Binding the color space to a surface with 
set_color_space
allows us to use the color spaces coming from the compositor via the
color_space_added event.

Can you explain why you want to do this differently?

> 
> You have declared some of the color-space as well known, do you think
> it will be useful to also let the
> client get the color_space interface, based on the well-known
> color-space.?
> Server on the other hand can have already built objects from the
> standard icc files, the interfaces of
> which can be passed to the client.

When the compositor loaded an icc profile for e.g. a display it should 
emit a
color_space_added event which then, if the color space is "well-known" 
(other
names were suggested) the zwp_color_space_v1.information event should 
say
that.

So I think what you suggest is already possible with this protocol.

> 
>> +    <event name="color_space_added">
>> +      <description summary="color space added">
>> +        Send after binding or when a new color space is added to
>> the system.
>> +      </description>
>> +      <arg name="color_space" type="new_id"
>> interface="zwp_color_space_v1"/>
>> +    </event>
>> +  </interface>
>> +
>> +  <interface name="zwp_color_space_v1" version="1">
>> +    <description summary="a color space">
>> +      A color space can be attached to a wl_surface and sends
>> +      information like the ICC profile to let the client perform
>> color
>> +      correction.
>> +    </description>
>> +
>> +    <event name="information">
>> +      <description summary="color space information">
>> +        Information describing the color space.
>> +
>> +        The icc argument contains a fd to the corresponding ICC
>> profile.
>> +        well-known can be used to easily identify a color-space.
>> +
>> +        A color space can be associated with a wl_output.
>> +      </description>
>> +      <arg name="icc" type="fd"/>
>> +      <arg name="well-known" type="uint"
>> enum="well_known_color_space"/>
>> +      <arg name="output" type="object" interface="wl_output"
>> allow-null="true"/>
>> +    </event>
>> +
> 
> When will this event be generated, should there be a request from a
> client via the color_space interface
> for the information? Will events be sent for each output, the surface
> is displayed on?
> 
>> +    <event name="removed">
>> +      <description summary="color space removed">
>> +        This event is sent when the color space is removed from the
>> system.
>> +        When this event is received, the client must destroy the
>> object.
>> +      </description>
>> +    </event>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="destroy the color space object">
>> +          Destroy the color_space object.
>> +      </description>
>> +    </request>
>> +  </interface>
>> +
>> +  <interface name="zwp_color_space_feedback_v1" version="1">
>> +    <description summary="color space feedback">
>> +      The surface content was converted to a number of color spaces
>> +      on the last content update. They get listed in decreasing
>> order
>> +      of importance by the converted event.
>> +      Once a color_space_feedback object has delivered a done
>> +      event it is automatically destroyed.
>> +    </description>
>> +
>> +    <event name="converted">
>> +      <description summary="color space conversion">
>> +        The surface was converted to a color space.
>> +      </description>
>> +      <arg name="color_space" type="object"
>> interface="zwp_color_space_v1"/>
>> +    </event>
>> +
> 
> So a client with a surface, will receive a series of these events for
> its surface, whenever the
> color space conversion takes place for that surface?
> Why do we need this interface, can the color_manager be used to send
> these events?

The client will receive the events on the next present when it created 
the
zwp_color_space_feedback_v1 object via
zwp_color_manager_v1.color_space_feedback.
This is strictly not needed but allows the client to choose a color 
space
to render to which will likely be used to display the surface on the 
next
present which in turn means that the compositor can skip color 
conversion.

I hope this answers all your questions. Feel free to keep questioning 
me.

I'll try to come up with a modification of this protocol that can handle 
HDR
based on your changes.

> 
> Thanks & Regards,
> Ankit
> 
>> +    <event name="done">
>> +      <description summary="done listing color space conversions">
>> +        All color space conversion have been listed.
>> +      </description>
>> +    </event>
>> +  </interface>
>> +
>> +</protocol>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 2/14/2019 1:27 PM, Sebastian Wick wrote:
> On 2019-02-14 08:13, Nautiyal, Ankit K via wayland-devel wrote:
>> Hi Sebastian,
>>
>> I am trying to extend Ole's color management protocol [1] to enable a
>> client to pass HDR meta data.
>> Added the modified protocol as weston protocol for the time being. [2]
>
> Thanks. That's useful.
>
>>
>> You have mention that the proposed protocol, ignores the HDR
>> calibration/profiling,  so do you suggest there should
>> be another protocol for that altogether or is there a possibility to
>> extend this for handling HDR metadata?
>
> I absolutely think that this can be extended for handling HDR.
>
>>
>> [1]
>> https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html 
>>
>> [2]
>> https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c 
>>
>>
>> Also, there are a few queries to understand the flow, please find
>> below inline:
>> On 2/14/2019 8:16 AM, Sebastian Wick wrote:
>>
>>> This protocol allows clients to attach a color space and rendering
>>> intent to a wl_surface. It further allows the client to be informed
>>> which color spaces a wl_surface was converted to on the last
>>> presented.
>>>
>>> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
>>> ---
>>> Makefile.am                                   |   1 +
>>> unstable/color-management/README              |   4 +
>>> .../color-management-unstable-v1.xml          | 183
>>> ++++++++++++++++++
>>> 3 files changed, 188 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 345ae6a..80abc1d 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -23,6 +23,7 @@ unstable_protocols =
>>> \
>>> unstable/xdg-decoration/xdg-decoration-unstable-v1.xml    \
>>>
>>>
>> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml 
>>
>>> \
>>> unstable/primary-selection/primary-selection-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..140f1e9
>>> --- /dev/null
>>> +++ b/unstable/color-management/README
>>> @@ -0,0 +1,4 @@
>>> +Color management protocol
>>> +
>>> +Maintainers:
>>> +Sebastian Wick <sebastian@sebastianwick.net>
>>> 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..1615fe6
>>> --- /dev/null
>>> +++ b/unstable/color-management/color-management-unstable-v1.xml
>>> @@ -0,0 +1,183 @@
>>> +<?xml version="1.0" encoding="UTF-8"?>
>>> +<protocol name="color_management_unstable_v1">
>>> +
>>> +  <copyright>
>>> +    Copyright © 2019 Sebastian Wick
>>> +    Copyright © 2019 Erwin Burema
>>> +
>>> +    Permission is hereby granted, free of charge, to any person
>>> obtaining a
>>> +    copy of this software and associated documentation files (the
>>> "Software"),
>>> +    to deal in the Software without restriction, including without
>>> limitation
>>> +    the rights to use, copy, modify, merge, publish, distribute,
>>> sublicense,
>>> +    and/or sell copies of the Software, and to permit persons to
>>> whom the
>>> +    Software is furnished to do so, subject to the following
>>> conditions:
>>> +
>>> +    The above copyright notice and this permission notice
>>> (including the next
>>> +    paragraph) shall be included in all copies or substantial
>>> portions of the
>>> +    Software.
>>> +
>>> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> EXPRESS OR
>>> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> MERCHANTABILITY,
>>> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
>>> EVENT SHALL
>>> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
>>> DAMAGES OR OTHER
>>> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>> ARISING
>>> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> OTHER
>>> +    DEALINGS IN THE SOFTWARE.
>>> +  </copyright>
>>> +
>>> +  <description summary="color management protocol">
>>> +    This protocol provides the ability to specify the color space
>>> +    of a wl_surface. If further enumerates the color spaces
>>> currently
>>> +    in the system and allows to query feedback about which color
>>> spaces
>>> +    a wl_surface was converted to on the last present.
>>> +    The idea behind the feedback system is to allow the client to
>>> do color
>>> +    conversion to a color space which will likely be used to show
>>> the surface
>>> +    which allows the compositor to skip the color conversion step.
>>> +  </description>
>>> +
>>> +  <interface name="zwp_color_manager_v1" version="1">
>>> +    <description summary="color manager">
>>> +      The color manager is a singleton global object that provides
>>> access
>>> +      to outputs' color spaces, let's you create new color spaces
>>> and attach
>>> +      a color space to surfaces.
>>> +    </description>
>>> +
>>> +    <enum name="render_intent">
>>> +      <description summary="render intent">
>>> +        render intents
>>> +      </description>
>>> +      <entry name="absolute" value="1"/>
>>> +      <entry name="relative" value="2"/>
>>> +      <entry name="perceptual" value="3"/>
>>> +      <entry name="saturation" value="4" />
>>> +    </enum>
>>> +
>>> +    <enum name="well_known_color_space">
>>> +      <description summary="well-known color spaces">
>>> +        Well-known color spaces
>>> +      </description>
>>> +      <entry name="none" value="0" summary="no known color space"
>>> />
>>> +      <entry name="sRGB" value="1" summary="sRGB color space" />
>>> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
>>> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
>>> +      <entry name="rec2020" value="4" summary="rec2020" />
>>> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq
>>> curve (HDR)" />
>>> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG
>>> curve (HDR)" />
>>> +    </enum>
>>> +
>>> +    <enum name="error">
>>> +      <description summary="fatal color manager errors">
>>> +        These fatal protocol errors may be emitted in response to
>>> +        illegal color management requests.
>>> +      </description>
>>> +      <entry name="invalid_icc_profile" value="0" summary="invalid
>>> ICC profile"/>
>>> +    </enum>
>>> +
>>> +    <request name="set_color_space">
>>> +      <description summary="set the color space of a surface">
>>> +        Set the color space of a surface. The color space is double
>>> buffered,
>>> +        and will be applied at the time wl_surface.commit of the
>>> corresponding
>>> +        wl_surface is called.
>>> +
>>> +        The render intent gives the compositor a hint what to
>>> optimize for
>>> +        in color space conversions.
>>> +
>>> +        If a surface has no color space set, sRGB and an arbitrary
>>> render
>>> +        intent will be assumed.
>>> +      </description>
>>> +      <arg name="surface" type="object" interface="wl_surface"/>
>>> +      <arg name="color_space" type="object"
>>> interface="zwp_color_space_v1"/>
>>> +      <arg name="render_intent" type="uint" enum="render_intent"/>
>>> +    </request>
>>> +
>>> +    <request name="color_space_feedback">
>>> +      <description summary="color space feedback">
>>> +        Request color space feedback for the current content
>>> submission
>>> +        on the given surface. This creates a new
>>> color_space_feedback
>>> +        object, which will deliver the feedback information once.
>>> If
>>> +        multiple color_space_feedback objects are created for the
>>> same
>>> +        submission, they will all deliver the same information.
>>> +
>>> +        For details on what information is returned, see the
>>> +        color_space_feedback interface.
>>> +      </description>
>>> +      <arg name="surface" type="object" interface="wl_surface"/>
>>> +      <arg name="feedback" type="new_id"
>>> interface="zwp_color_space_feedback_v1"/>
>>> +    </request>
>>> +
>>> +    <request name="color_space_from_icc">
>>> +      <description summary="create a color space from an ICC
>>> profile">
>>> +        Create a color space from an ICC profile. Only three
>>> channel
>>> +        profiles are allowed.
>>> +      </description>
>>> +      <arg name="color_space" type="new_id"
>>> interface="zwp_color_space_v1"/>
>>> +      <arg name="icc" type="fd"/>
>>> +    </request>
>>> +
>>
>> If I understand it correctly,
>> the client first sends a request for getting color-space for an icc
>> file, receives the color_space interface.
>> If we can add the surface in this requests, it can be tied to the
>> color-space interface, and later set color_space,
>> without the surface.
>
> There is two ways to get a color_space object. The first one is to 
> listen for
> color_space_added events and the other, like you noted, is to call
> color_space_from_icc.
> However, I don't see why a color space should should be tied to a 
> wl_surface
> from the beginning. Binding the color space to a surface with 
> set_color_space
> allows us to use the color spaces coming from the compositor via the
> color_space_added event.
>
> Can you explain why you want to do this differently?

Sorry, I missed the color_space_added event.
I got it now. So as soon as the client starts, and binding of the client 
object to the
server, it receives a series of events, notifying it with the well-known 
colorspaces.
Clients stores each of the color_space interfaces and choose it deems best.

Thanks for clarifying, this answers my other question as well, regarding 
well-known color-spaces.

I still wonder about the 'information' event sent by the 
color_space_interface.
When will this event be sent. I think this should be in response to a 
client request for the
color-space information via the color_space_interface.
Also, such an event will be sent for which all outputs?

>>
>> You have declared some of the color-space as well known, do you think
>> it will be useful to also let the
>> client get the color_space interface, based on the well-known
>> color-space.?
>> Server on the other hand can have already built objects from the
>> standard icc files, the interfaces of
>> which can be passed to the client.
>
> When the compositor loaded an icc profile for e.g. a display it should 
> emit a
> color_space_added event which then, if the color space is "well-known" 
> (other
> names were suggested) the zwp_color_space_v1.information event should say
> that.
>
> So I think what you suggest is already possible with this protocol.
>
>>
>>> +    <event name="color_space_added">
>>> +      <description summary="color space added">
>>> +        Send after binding or when a new color space is added to
>>> the system.
>>> +      </description>
>>> +      <arg name="color_space" type="new_id"
>>> interface="zwp_color_space_v1"/>
>>> +    </event>
>>> +  </interface>
>>> +
>>> +  <interface name="zwp_color_space_v1" version="1">
>>> +    <description summary="a color space">
>>> +      A color space can be attached to a wl_surface and sends
>>> +      information like the ICC profile to let the client perform
>>> color
>>> +      correction.
>>> +    </description>
>>> +
>>> +    <event name="information">
>>> +      <description summary="color space information">
>>> +        Information describing the color space.
>>> +
>>> +        The icc argument contains a fd to the corresponding ICC
>>> profile.
>>> +        well-known can be used to easily identify a color-space.
>>> +
>>> +        A color space can be associated with a wl_output.
>>> +      </description>
>>> +      <arg name="icc" type="fd"/>
>>> +      <arg name="well-known" type="uint"
>>> enum="well_known_color_space"/>
>>> +      <arg name="output" type="object" interface="wl_output"
>>> allow-null="true"/>
>>> +    </event>
>>> +
>>
>> When will this event be generated, should there be a request from a
>> client via the color_space interface
>> for the information? Will events be sent for each output, the surface
>> is displayed on?
>>
>>> +    <event name="removed">
>>> +      <description summary="color space removed">
>>> +        This event is sent when the color space is removed from the
>>> system.
>>> +        When this event is received, the client must destroy the
>>> object.
>>> +      </description>
>>> +    </event>
>>> +
>>> +    <request name="destroy" type="destructor">
>>> +      <description summary="destroy the color space object">
>>> +          Destroy the color_space object.
>>> +      </description>
>>> +    </request>
>>> +  </interface>
>>> +
>>> +  <interface name="zwp_color_space_feedback_v1" version="1">
>>> +    <description summary="color space feedback">
>>> +      The surface content was converted to a number of color spaces
>>> +      on the last content update. They get listed in decreasing
>>> order
>>> +      of importance by the converted event.
>>> +      Once a color_space_feedback object has delivered a done
>>> +      event it is automatically destroyed.
>>> +    </description>
>>> +
>>> +    <event name="converted">
>>> +      <description summary="color space conversion">
>>> +        The surface was converted to a color space.
>>> +      </description>
>>> +      <arg name="color_space" type="object"
>>> interface="zwp_color_space_v1"/>
>>> +    </event>
>>> +
>>
>> So a client with a surface, will receive a series of these events for
>> its surface, whenever the
>> color space conversion takes place for that surface?
>> Why do we need this interface, can the color_manager be used to send
>> these events?
>
> The client will receive the events on the next present when it created 
> the
> zwp_color_space_feedback_v1 object via
> zwp_color_manager_v1.color_space_feedback.
> This is strictly not needed but allows the client to choose a color space
> to render to which will likely be used to display the surface on the next
> present which in turn means that the compositor can skip color 
> conversion.
>
> I hope this answers all your questions. Feel free to keep questioning me.
>
> I'll try to come up with a modification of this protocol that can 
> handle HDR
> based on your changes.

Thanks, that will be great.
Should you have anything to discuss in this regard, please let me know 
through mail, or IRC: aknautiy

Regards,
Ankit

>
>>
>> Thanks & Regards,
>> Ankit
>>
>>> +    <event name="done">
>>> +      <description summary="done listing color space conversions">
>>> +        All color space conversion have been listed.
>>> +      </description>
>>> +    </event>
>>> +  </interface>
>>> +
>>> +</protocol>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Wed, 2019-02-13 at 21:47 -0700, Chris Murphy wrote:
> On Wed, Feb 13, 2019 at 7:55 PM Sebastian Wick
> <sebastian@sebastianwick.net> wrote:
> 
> 
> > +      <entry name="absolute" value="1"/>
> 
> I suggest ICC spec language.  'ICC-absolute colorimetric'
> 
> > +      <entry name="relative" value="2"/>
> 
> 'media-relative colorimetric'
> 
> 
> > +      <entry name="none" value="0" summary="no known color space" />
> 
> I think this is 'deviceRGB' although it could be 'unknown'.
> Practically, it could only be unknown if the values aren't being
> displayed or output anywhere. The instant RGB values are displayed
> anywhere, the color space is knowable, therefore it's at least
> deviceRGB. But unknown is also consistent with EXIF.
> 
> And 'color space' can be assumed.
> 
> > +      <entry name="sRGB" value="1" summary="sRGB color space" />
> 
> Summary probably should be 'sRGB IEC61966-2.1' and again 'color space'
> can be assumed.
> 
> > +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> 
> Summary probably should be 'Adobe RGB (1998)'

In the Kernel, AdobeRGB has been replaced with opRGB. Should this be
name="opRGB", summary="opRGB IEC 61966-2-5"?

regards
Philipp
Regards
Shashank

> -----Original Message-----

> From: wayland-devel [mailto:wayland-devel-bounces@lists.freedesktop.org] On

> Behalf Of Sebastian Wick

> Sent: Thursday, February 14, 2019 12:13 PM

> To: wayland-devel@lists.freedesktop.org

> Subject: Re: [RFC wayland-protocols 1/1] unstable: add color management protocol

> 

> On 2019-02-14 05:55, Sharma, Shashank via wayland-devel wrote:

> > Hello Sebastian,

> > My comments inline.

> >

> > Regards

> > Shashank

> >> -----Original Message-----

> >> From: wayland-devel

> >> [mailto:wayland-devel-bounces@lists.freedesktop.org] On Behalf Of

> >> Sebastian Wick

> >> Sent: Thursday, February 14, 2019 8:16 AM

> >> To: wayland-devel@lists.freedesktop.org

> >> Cc: Sebastian Wick <sebastian@sebastianwick.net>

> >> Subject: [RFC wayland-protocols 1/1] unstable: add color management

> >> protocol

> >>

> >> This protocol allows clients to attach a color space and rendering

> >> intent to a wl_surface. It further allows the client to be informed

> >> which color spaces a wl_surface was converted to on the last

> >> presented.

> >>

> >> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>

> >> ---

> >>  Makefile.am                                   |   1 +

> >>  unstable/color-management/README              |   4 +

> >>  .../color-management-unstable-v1.xml          | 183

> >> ++++++++++++++++++

> >>  3 files changed, 188 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 345ae6a..80abc1d 100644

> >> --- a/Makefile.am

> >> +++ b/Makefile.am

> >> @@ -23,6 +23,7 @@ unstable_protocols =

> >> 		\

> >>  	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\

> >>

> >>

> >> unstable/linux-explicit-synchronization/linux-explicit-synchronizatio

> >> n-

> >> unstable-v1.xml \

> >>  	unstable/primary-selection/primary-selection-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..140f1e9

> >> --- /dev/null

> >> +++ b/unstable/color-management/README

> >> @@ -0,0 +1,4 @@

> >> +Color management protocol

> >> +

> >> +Maintainers:

> >> +Sebastian Wick <sebastian@sebastianwick.net>

> >> 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..1615fe6

> >> --- /dev/null

> >> +++ b/unstable/color-management/color-management-unstable-v1.xml

> >> @@ -0,0 +1,183 @@

> >> +<?xml version="1.0" encoding="UTF-8"?> <protocol

> >> +name="color_management_unstable_v1">

> >> +

> >> +  <copyright>

> >> +    Copyright © 2019 Sebastian Wick

> >> +    Copyright © 2019 Erwin Burema

> >> +

> >> +    Permission is hereby granted, free of charge, to any person

> >> obtaining a

> >> +    copy of this software and associated documentation files (the

> >> "Software"),

> >> +    to deal in the Software without restriction, including without

> >> limitation

> >> +    the rights to use, copy, modify, merge, publish, distribute,

> >> sublicense,

> >> +    and/or sell copies of the Software, and to permit persons to

> >> + whom

> >> the

> >> +    Software is furnished to do so, subject to the following

> >> conditions:

> >> +

> >> +    The above copyright notice and this permission notice (including

> >> the next

> >> +    paragraph) shall be included in all copies or substantial

> >> portions of the

> >> +    Software.

> >> +

> >> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

> >> EXPRESS OR

> >> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

> >> MERCHANTABILITY,

> >> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO

> >> EVENT

> >> SHALL

> >> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,

> >> + DAMAGES

> >> OR OTHER

> >> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,

> >> ARISING

> >> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR

> >> OTHER

> >> +    DEALINGS IN THE SOFTWARE.

> >> +  </copyright>

> >> +

> >> +  <description summary="color management protocol">

> >> +    This protocol provides the ability to specify the color space

> >> +    of a wl_surface. If further enumerates the color spaces currently

> >> +    in the system and allows to query feedback about which color

> >> spaces

> >> +    a wl_surface was converted to on the last present.

> >> +    The idea behind the feedback system is to allow the client to do

> >> color

> >> +    conversion to a color space which will likely be used to show

> >> + the

> >> surface

> >> +    which allows the compositor to skip the color conversion step.

> >> +  </description>

> >> +

> >> +  <interface name="zwp_color_manager_v1" version="1">

> >> +    <description summary="color manager">

> >> +      The color manager is a singleton global object that provides

> >> access

> >> +      to outputs' color spaces, let's you create new color spaces

> >> + and

> >> attach

> >> +      a color space to surfaces.

> >> +    </description>

> >> +

> >> +    <enum name="render_intent">

> >> +      <description summary="render intent">

> >> +        render intents

> >> +      </description>

> >> +      <entry name="absolute" value="1"/>

> >> +      <entry name="relative" value="2"/>

> >> +      <entry name="perceptual" value="3"/>

> >> +      <entry name="saturation" value="4" />

> > Would you elaborate a bit more on what do we want to achieve with

> > render-intent ? How can the compositor utilize this filed during color

> > conversion ?

> 

> It's about how to handle colors which are outside of the destionation gamut

> https://en.wikipedia.org/wiki/Color_management#Rendering_intent

> 

> >> +    </enum>

> >> +

> >> +    <enum name="well_known_color_space">

> >> +      <description summary="well-known color spaces">

> > Its slightly difficult to define what is the definition of a

> > "well-known" color space, as different use cases may have their own

> > favorite. May be we can call it "general-purpose" or "standard" or

> > something in those line.

> >> +        Well-known color spaces

> >> +      </description>

> >> +      <entry name="none" value="0" summary="no known color space" />

> >> +      <entry name="sRGB" value="1" summary="sRGB color space" />

> >> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />

> >> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />

> > I guess we mean DCI-P3 here

> >> +      <entry name="rec2020" value="4" summary="rec2020" />

> >> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq

> >> curve (HDR)"

> >> />

> >> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG

> >> curve

> >> (HDR)" />

> > Well, this is slightly off the chart for me. If I understood this

> > correctly, the cover letter talks about the intent is to focus on

> > Colorspace only, but here we are differentiating enum values based on

> > their EOTF HDR curve, which is the only difference between these three

> > colorspaces. Then why not just mind the colorspace regardless of the

> > HDR curve.

> 

> A color space consits of three primaries, the white point and the EOTF/OETF.

> Just because two color spaces share the same color gamut doesn't mean that they're

> the same. You're right though that a conversion between those color spaces would

> not require a render intent but since we don't know which color spaces we end up

> having to convert to we need a render intent always.

> 

Well, REC2020 with HLG/PQ curves are not different color spaces, but they are the same color space with different non-linear curves. The colorspace here still remains BT2020 and its primaries are still the same, it's just that the encoding is being done using different curves. 

> The point of the enum is to give some ICCs a recognizable name so clients have the

> ability to identify those color spaces without having to poke the ICC profile.

> 


Having a separate section to list down which curve this combination follows, will be good enough. Just like monitors which follow CEA-861-G do in EDID, they just indicate in a byte that which EOTF curve they support, and the driver/compositor unit can note this capability and apply a matching output curve while sending the data to display.  

> >

> > On the other hand, we can accommodate the HDR specific information

> > also, like the EOTF curve type, and the HDR metadata type and content

> > for the frame, if we can add some additional filed in this same

> > protocol. So the colorspace information will remain the same, and the

> > presence of HDR metadata type / content filed can indicate if the

> > current frame is HDR BT2020 frame or SDR BT2020 frame.

> 

> This is where my lack of knowledge about HDR standards might become a problem.

> My understanding right now is that the HDR standards define a color space (which

> includes EOTF) and then has (potentially dynamic) metadata which specifies the

> luminance.

> 

Again, A HDR standard (take SMPTE St-2084 for example) does not define a new color space, they just define a new curve (EOTF/OETF) in an existing color space (Like BT2020/Rec709 etc), which allows them to cover a very 'H'igh 'D'ynamic 'R'ange of brightness values (very dark to very bright, 0-10000 cd/m2 or nits). This curve is applied to accommodate this high range of pixels, within the color depth of 10/12/16 BPC, define in BT2020 spec, which would have taken close to 40-48 BPC in a linear data representation. 

> If my understanding is correct a request which sets the HDR metadata would be

> sufficient. Another request to set a custom tone curve would be highly useful, too.

> 

Agree. 
> >

> > Ankit from my team, has something similar being implemented to address

> > the color management and HDR requirements in the same protocol. May be

> > you guys can merge your solutions and come-up with something even more

> > exiting and usable.

> 

> I'd love to hear more about that. Feel free to contact me on IRC (swick), mail or just on

> this list.

> 

I think you guys are already in talking terms, so already doing good here :). 

- Shashank
> >> +    </enum>

> >> +

> >> +    <enum name="error">

> >> +      <description summary="fatal color manager errors">

> >> +        These fatal protocol errors may be emitted in response to

> >> +        illegal color management requests.

> >> +      </description>

> >> +      <entry name="invalid_icc_profile" value="0" summary="invalid

> >> ICC profile"/>

> >> +    </enum>

> >> +

> >> +    <request name="set_color_space">

> >> +      <description summary="set the color space of a surface">

> >> +        Set the color space of a surface. The color space is double

> >> buffered,

> >> +        and will be applied at the time wl_surface.commit of the

> >> corresponding

> >> +        wl_surface is called.

> >> +

> >> +        The render intent gives the compositor a hint what to

> >> optimize for

> >> +        in color space conversions.

> >> +

> >> +        If a surface has no color space set, sRGB and an arbitrary

> >> render

> >> +        intent will be assumed.

> >> +      </description>

> >> +      <arg name="surface" type="object" interface="wl_surface"/>

> >> +      <arg name="color_space" type="object"

> >> interface="zwp_color_space_v1"/>

> >> +      <arg name="render_intent" type="uint" enum="render_intent"/>

> >> +    </request>

> >> +

> >> +    <request name="color_space_feedback">

> >> +      <description summary="color space feedback">

> >> +        Request color space feedback for the current content

> >> submission

> >> +        on the given surface. This creates a new color_space_feedback

> >> +        object, which will deliver the feedback information once. If

> >> +        multiple color_space_feedback objects are created for the

> >> same

> >> +        submission, they will all deliver the same information.

> >> +

> >> +        For details on what information is returned, see the

> >> +        color_space_feedback interface.

> >> +      </description>

> >> +      <arg name="surface" type="object" interface="wl_surface"/>

> >> +      <arg name="feedback" type="new_id"

> >> interface="zwp_color_space_feedback_v1"/>

> >> +    </request>

> >> +

> >> +    <request name="color_space_from_icc">

> >> +      <description summary="create a color space from an ICC

> >> profile">

> >> +        Create a color space from an ICC profile. Only three channel

> >> +        profiles are allowed.

> >> +      </description>

> >> +      <arg name="color_space" type="new_id"

> >> interface="zwp_color_space_v1"/>

> >> +      <arg name="icc" type="fd"/>

> >> +    </request>

> >> +

> >> +    <event name="color_space_added">

> >> +      <description summary="color space added">

> >> +        Send after binding or when a new color space is added to the

> >> system.

> >> +      </description>

> >> +      <arg name="color_space" type="new_id"

> >> interface="zwp_color_space_v1"/>

> >> +    </event>

> >> +  </interface>

> >> +

> >> +  <interface name="zwp_color_space_v1" version="1">

> >> +    <description summary="a color space">

> >> +      A color space can be attached to a wl_surface and sends

> >> +      information like the ICC profile to let the client perform

> >> color

> >> +      correction.

> >> +    </description>

> >> +

> >> +    <event name="information">

> >> +      <description summary="color space information">

> >> +        Information describing the color space.

> >> +

> >> +        The icc argument contains a fd to the corresponding ICC

> >> profile.

> >> +        well-known can be used to easily identify a color-space.

> >> +

> >> +        A color space can be associated with a wl_output.

> >> +      </description>

> >> +      <arg name="icc" type="fd"/>

> >> +      <arg name="well-known" type="uint"

> >> enum="well_known_color_space"/>

> >> +      <arg name="output" type="object" interface="wl_output"

> >> allow-null="true"/>

> >> +    </event>

> >> +

> >> +    <event name="removed">

> >> +      <description summary="color space removed">

> >> +        This event is sent when the color space is removed from the

> >> system.

> >> +        When this event is received, the client must destroy the

> >> object.

> >> +      </description>

> >> +    </event>

> >> +

> >> +    <request name="destroy" type="destructor">

> >> +      <description summary="destroy the color space object">

> >> +	      Destroy the color_space object.

> >> +      </description>

> >> +    </request>

> >> +  </interface>

> >> +

> >> +  <interface name="zwp_color_space_feedback_v1" version="1">

> >> +    <description summary="color space feedback">

> >> +      The surface content was converted to a number of color spaces

> >> +      on the last content update. They get listed in decreasing order

> >> +      of importance by the converted event.

> >> +      Once a color_space_feedback object has delivered a done

> >> +      event it is automatically destroyed.

> >> +    </description>

> >> +

> >> +    <event name="converted">

> >> +      <description summary="color space conversion">

> >> +        The surface was converted to a color space.

> >> +      </description>

> >> +      <arg name="color_space" type="object"

> >> interface="zwp_color_space_v1"/>

> >> +    </event>

> >> +

> >> +    <event name="done">

> >> +      <description summary="done listing color space conversions">

> >> +        All color space conversion have been listed.

> >> +      </description>

> >> +    </event>

> >> +  </interface>

> >> +

> >> +</protocol>

> >> --

> >> 2.20.1

> >>

> >> _______________________________________________

> >> wayland-devel mailing list

> >> wayland-devel@lists.freedesktop.org

> >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

> > _______________________________________________

> > wayland-devel mailing list

> > wayland-devel@lists.freedesktop.org

> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel

> _______________________________________________

> wayland-devel mailing list

> wayland-devel@lists.freedesktop.org

> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, 14 Feb 2019 at 16:39, Sharma, Shashank via wayland-devel
<wayland-devel@lists.freedesktop.org> wrote:

Hi,

>
> Regards
> Shashank
>
> > -----Original Message-----
> > From: wayland-devel [mailto:wayland-devel-bounces@lists.freedesktop.org] On
> > Behalf Of Sebastian Wick
> > Sent: Thursday, February 14, 2019 12:13 PM
> > To: wayland-devel@lists.freedesktop.org
> > Subject: Re: [RFC wayland-protocols 1/1] unstable: add color management protocol
> >
> > On 2019-02-14 05:55, Sharma, Shashank via wayland-devel wrote:
> > > Hello Sebastian,
> > > My comments inline.
> > >
> > > Regards
> > > Shashank
> > >> -----Original Message-----
> > >> From: wayland-devel
> > >> [mailto:wayland-devel-bounces@lists.freedesktop.org] On Behalf Of
> > >> Sebastian Wick
> > >> Sent: Thursday, February 14, 2019 8:16 AM
> > >> To: wayland-devel@lists.freedesktop.org
> > >> Cc: Sebastian Wick <sebastian@sebastianwick.net>
> > >> Subject: [RFC wayland-protocols 1/1] unstable: add color management
> > >> protocol
> > >>
> > >> This protocol allows clients to attach a color space and rendering
> > >> intent to a wl_surface. It further allows the client to be informed
> > >> which color spaces a wl_surface was converted to on the last
> > >> presented.
> > >>
> > >> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
> > >> ---
> > >>  Makefile.am                                   |   1 +
> > >>  unstable/color-management/README              |   4 +
> > >>  .../color-management-unstable-v1.xml          | 183
> > >> ++++++++++++++++++
> > >>  3 files changed, 188 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 345ae6a..80abc1d 100644
> > >> --- a/Makefile.am
> > >> +++ b/Makefile.am
> > >> @@ -23,6 +23,7 @@ unstable_protocols =
> > >>            \
> > >>    unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> > >>
> > >>
> > >> unstable/linux-explicit-synchronization/linux-explicit-synchronizatio
> > >> n-
> > >> unstable-v1.xml \
> > >>    unstable/primary-selection/primary-selection-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..140f1e9
> > >> --- /dev/null
> > >> +++ b/unstable/color-management/README
> > >> @@ -0,0 +1,4 @@
> > >> +Color management protocol
> > >> +
> > >> +Maintainers:
> > >> +Sebastian Wick <sebastian@sebastianwick.net>
> > >> 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..1615fe6
> > >> --- /dev/null
> > >> +++ b/unstable/color-management/color-management-unstable-v1.xml
> > >> @@ -0,0 +1,183 @@
> > >> +<?xml version="1.0" encoding="UTF-8"?> <protocol
> > >> +name="color_management_unstable_v1">
> > >> +
> > >> +  <copyright>
> > >> +    Copyright © 2019 Sebastian Wick
> > >> +    Copyright © 2019 Erwin Burema
> > >> +
> > >> +    Permission is hereby granted, free of charge, to any person
> > >> obtaining a
> > >> +    copy of this software and associated documentation files (the
> > >> "Software"),
> > >> +    to deal in the Software without restriction, including without
> > >> limitation
> > >> +    the rights to use, copy, modify, merge, publish, distribute,
> > >> sublicense,
> > >> +    and/or sell copies of the Software, and to permit persons to
> > >> + whom
> > >> the
> > >> +    Software is furnished to do so, subject to the following
> > >> conditions:
> > >> +
> > >> +    The above copyright notice and this permission notice (including
> > >> the next
> > >> +    paragraph) shall be included in all copies or substantial
> > >> portions of the
> > >> +    Software.
> > >> +
> > >> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > >> EXPRESS OR
> > >> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > >> MERCHANTABILITY,
> > >> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > >> EVENT
> > >> SHALL
> > >> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > >> + DAMAGES
> > >> OR OTHER
> > >> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > >> ARISING
> > >> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > >> OTHER
> > >> +    DEALINGS IN THE SOFTWARE.
> > >> +  </copyright>
> > >> +
> > >> +  <description summary="color management protocol">
> > >> +    This protocol provides the ability to specify the color space
> > >> +    of a wl_surface. If further enumerates the color spaces currently
> > >> +    in the system and allows to query feedback about which color
> > >> spaces
> > >> +    a wl_surface was converted to on the last present.
> > >> +    The idea behind the feedback system is to allow the client to do
> > >> color
> > >> +    conversion to a color space which will likely be used to show
> > >> + the
> > >> surface
> > >> +    which allows the compositor to skip the color conversion step.
> > >> +  </description>
> > >> +
> > >> +  <interface name="zwp_color_manager_v1" version="1">
> > >> +    <description summary="color manager">
> > >> +      The color manager is a singleton global object that provides
> > >> access
> > >> +      to outputs' color spaces, let's you create new color spaces
> > >> + and
> > >> attach
> > >> +      a color space to surfaces.
> > >> +    </description>
> > >> +
> > >> +    <enum name="render_intent">
> > >> +      <description summary="render intent">
> > >> +        render intents
> > >> +      </description>
> > >> +      <entry name="absolute" value="1"/>
> > >> +      <entry name="relative" value="2"/>
> > >> +      <entry name="perceptual" value="3"/>
> > >> +      <entry name="saturation" value="4" />
> > > Would you elaborate a bit more on what do we want to achieve with
> > > render-intent ? How can the compositor utilize this filed during color
> > > conversion ?
> >
> > It's about how to handle colors which are outside of the destionation gamut
> > https://en.wikipedia.org/wiki/Color_management#Rendering_intent
> >
> > >> +    </enum>
> > >> +
> > >> +    <enum name="well_known_color_space">
> > >> +      <description summary="well-known color spaces">
> > > Its slightly difficult to define what is the definition of a
> > > "well-known" color space, as different use cases may have their own
> > > favorite. May be we can call it "general-purpose" or "standard" or
> > > something in those line.
> > >> +        Well-known color spaces
> > >> +      </description>
> > >> +      <entry name="none" value="0" summary="no known color space" />
> > >> +      <entry name="sRGB" value="1" summary="sRGB color space" />
> > >> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> > >> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> > > I guess we mean DCI-P3 here
> > >> +      <entry name="rec2020" value="4" summary="rec2020" />
> > >> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq
> > >> curve (HDR)"
> > >> />
> > >> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG
> > >> curve
> > >> (HDR)" />
> > > Well, this is slightly off the chart for me. If I understood this
> > > correctly, the cover letter talks about the intent is to focus on
> > > Colorspace only, but here we are differentiating enum values based on
> > > their EOTF HDR curve, which is the only difference between these three
> > > colorspaces. Then why not just mind the colorspace regardless of the
> > > HDR curve.
> >
> > A color space consits of three primaries, the white point and the EOTF/OETF.
> > Just because two color spaces share the same color gamut doesn't mean that they're
> > the same. You're right though that a conversion between those color spaces would
> > not require a render intent but since we don't know which color spaces we end up
> > having to convert to we need a render intent always.
> >
> Well, REC2020 with HLG/PQ curves are not different color spaces, but they are the same color space with different non-linear curves. The colorspace here still remains BT2020 and its primaries are still the same, it's just that the encoding is being done using different curves.

From a color management perspective that makes them different color
spaces, a color space is not just its primaries but also the curves
(for example sRGB primaries with a linear curve, which is for example
used in blender is not the same as sRGB, another example would be
ACEScg (linear scene referred) vs ACEScc (log scene referred) both use
the same primaries but one is linear and the other is log (scene
referred effectively means no upper bound to lightness))

>
> > The point of the enum is to give some ICCs a recognizable name so clients have the
> > ability to identify those color spaces without having to poke the ICC profile.
> >
>
> Having a separate section to list down which curve this combination follows, will be good enough. Just like monitors which follow CEA-861-G do in EDID, they just indicate in a byte that which EOTF curve they support, and the driver/compositor unit can note this capability and apply a matching output curve while sending the data to display.

Although this is not a bad idea since it would be a lot more flexible
>
> > >
> > > On the other hand, we can accommodate the HDR specific information
> > > also, like the EOTF curve type, and the HDR metadata type and content
> > > for the frame, if we can add some additional filed in this same
> > > protocol. So the colorspace information will remain the same, and the
> > > presence of HDR metadata type / content filed can indicate if the
> > > current frame is HDR BT2020 frame or SDR BT2020 frame.
> >
> > This is where my lack of knowledge about HDR standards might become a problem.
> > My understanding right now is that the HDR standards define a color space (which
> > includes EOTF) and then has (potentially dynamic) metadata which specifies the
> > luminance.
> >
> Again, A HDR standard (take SMPTE St-2084 for example) does not define a new color space, they just define a new curve (EOTF/OETF) in an existing color space (Like BT2020/Rec709 etc), which allows them to cover a very 'H'igh 'D'ynamic 'R'ange of brightness values (very dark to very bright, 0-10000 cd/m2 or nits). This curve is applied to accommodate this high range of pixels, within the color depth of 10/12/16 BPC, define in BT2020 spec, which would have taken close to 40-48 BPC in a linear data representation.

Just to repeat a different EOTF does make a different color space (at
least from a color management perspective) especially considering a
non-HDR space won't span the full brightness values of a HDR space,
this is especially a concern when there is a need to compose HDR and
non-HDR content together. The best option for that is to convert both
to scene linear (which is per definition a HDR space) compose and then
convert back to a proper output space.

>
> > If my understanding is correct a request which sets the HDR metadata would be
> > sufficient. Another request to set a custom tone curve would be highly useful, too.
> >
> Agree.
> > >
> > > Ankit from my team, has something similar being implemented to address
> > > the color management and HDR requirements in the same protocol. May be
> > > you guys can merge your solutions and come-up with something even more
> > > exiting and usable.
> >
> > I'd love to hear more about that. Feel free to contact me on IRC (swick), mail or just on
> > this list.
> >
> I think you guys are already in talking terms, so already doing good here :).
>
> - Shashank
> > >> +    </enum>
> > >> +
> > >> +    <enum name="error">
> > >> +      <description summary="fatal color manager errors">
> > >> +        These fatal protocol errors may be emitted in response to
> > >> +        illegal color management requests.
> > >> +      </description>
> > >> +      <entry name="invalid_icc_profile" value="0" summary="invalid
> > >> ICC profile"/>
> > >> +    </enum>
> > >> +
> > >> +    <request name="set_color_space">
> > >> +      <description summary="set the color space of a surface">
> > >> +        Set the color space of a surface. The color space is double
> > >> buffered,
> > >> +        and will be applied at the time wl_surface.commit of the
> > >> corresponding
> > >> +        wl_surface is called.
> > >> +
> > >> +        The render intent gives the compositor a hint what to
> > >> optimize for
> > >> +        in color space conversions.
> > >> +
> > >> +        If a surface has no color space set, sRGB and an arbitrary
> > >> render
> > >> +        intent will be assumed.
> > >> +      </description>
> > >> +      <arg name="surface" type="object" interface="wl_surface"/>
> > >> +      <arg name="color_space" type="object"
> > >> interface="zwp_color_space_v1"/>
> > >> +      <arg name="render_intent" type="uint" enum="render_intent"/>
> > >> +    </request>
> > >> +
> > >> +    <request name="color_space_feedback">
> > >> +      <description summary="color space feedback">
> > >> +        Request color space feedback for the current content
> > >> submission
> > >> +        on the given surface. This creates a new color_space_feedback
> > >> +        object, which will deliver the feedback information once. If
> > >> +        multiple color_space_feedback objects are created for the
> > >> same
> > >> +        submission, they will all deliver the same information.
> > >> +
> > >> +        For details on what information is returned, see the
> > >> +        color_space_feedback interface.
> > >> +      </description>
> > >> +      <arg name="surface" type="object" interface="wl_surface"/>
> > >> +      <arg name="feedback" type="new_id"
> > >> interface="zwp_color_space_feedback_v1"/>
> > >> +    </request>
> > >> +
> > >> +    <request name="color_space_from_icc">
> > >> +      <description summary="create a color space from an ICC
> > >> profile">
> > >> +        Create a color space from an ICC profile. Only three channel
> > >> +        profiles are allowed.
> > >> +      </description>
> > >> +      <arg name="color_space" type="new_id"
> > >> interface="zwp_color_space_v1"/>
> > >> +      <arg name="icc" type="fd"/>
> > >> +    </request>
> > >> +
> > >> +    <event name="color_space_added">
> > >> +      <description summary="color space added">
> > >> +        Send after binding or when a new color space is added to the
> > >> system.
> > >> +      </description>
> > >> +      <arg name="color_space" type="new_id"
> > >> interface="zwp_color_space_v1"/>
> > >> +    </event>
> > >> +  </interface>
> > >> +
> > >> +  <interface name="zwp_color_space_v1" version="1">
> > >> +    <description summary="a color space">
> > >> +      A color space can be attached to a wl_surface and sends
> > >> +      information like the ICC profile to let the client perform
> > >> color
> > >> +      correction.
> > >> +    </description>
> > >> +
> > >> +    <event name="information">
> > >> +      <description summary="color space information">
> > >> +        Information describing the color space.
> > >> +
> > >> +        The icc argument contains a fd to the corresponding ICC
> > >> profile.
> > >> +        well-known can be used to easily identify a color-space.
> > >> +
> > >> +        A color space can be associated with a wl_output.
> > >> +      </description>
> > >> +      <arg name="icc" type="fd"/>
> > >> +      <arg name="well-known" type="uint"
> > >> enum="well_known_color_space"/>
> > >> +      <arg name="output" type="object" interface="wl_output"
> > >> allow-null="true"/>
> > >> +    </event>
> > >> +
> > >> +    <event name="removed">
> > >> +      <description summary="color space removed">
> > >> +        This event is sent when the color space is removed from the
> > >> system.
> > >> +        When this event is received, the client must destroy the
> > >> object.
> > >> +      </description>
> > >> +    </event>
> > >> +
> > >> +    <request name="destroy" type="destructor">
> > >> +      <description summary="destroy the color space object">
> > >> +        Destroy the color_space object.
> > >> +      </description>
> > >> +    </request>
> > >> +  </interface>
> > >> +
> > >> +  <interface name="zwp_color_space_feedback_v1" version="1">
> > >> +    <description summary="color space feedback">
> > >> +      The surface content was converted to a number of color spaces
> > >> +      on the last content update. They get listed in decreasing order
> > >> +      of importance by the converted event.
> > >> +      Once a color_space_feedback object has delivered a done
> > >> +      event it is automatically destroyed.
> > >> +    </description>
> > >> +
> > >> +    <event name="converted">
> > >> +      <description summary="color space conversion">
> > >> +        The surface was converted to a color space.
> > >> +      </description>
> > >> +      <arg name="color_space" type="object"
> > >> interface="zwp_color_space_v1"/>
> > >> +    </event>
> > >> +
> > >> +    <event name="done">
> > >> +      <description summary="done listing color space conversions">
> > >> +        All color space conversion have been listed.
> > >> +      </description>
> > >> +    </event>
> > >> +  </interface>
> > >> +
> > >> +</protocol>
> > >> --
> > >> 2.20.1
> > >>
> > >> _______________________________________________
> > >> wayland-devel mailing list
> > >> wayland-devel@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi,

On Thu, 14 Feb 2019 at 16:40, Nautiyal, Ankit K via wayland-devel
<wayland-devel@lists.freedesktop.org> wrote:
>
> Hi Sebastian,
>
> I am trying to extend Ole's color management protocol [1] to enable a client to pass HDR meta data.
> Added the modified protocol as weston protocol for the time being. [2]
>

As far as I can tell Ole's color management assumes that all ICC
profiles can be used by a wayland compositor this won't really be true
in practice since those profiles can be defined with up to 15 channels
(see section 7.2.6 of
http://color.org/specification/ICC1v43_2010-12.pdf; although the most
used commonly would be CMYK ) at least that is how I read it, I do
read it like this mostly due to the inclusion of device link profiles,
which I think where intended so the compositor could go from program
internal to intended device while for other (overlapping/cloned)
outputs it can de from that internal to other outputs with a
compositor defined transform, this works for RGB profiles but not so
much for CMYK or other more exotic color spaces. Programs that use
those would probably prefer to render directly to the display color
space (which makes a device link unnecessary).

> You have mention that the proposed protocol, ignores the HDR calibration/profiling,  so do you suggest there should
> be another protocol for that altogether or is there a possibility to extend this for handling HDR metadata?

On pixls.us (thread can be found here:
https://discuss.pixls.us/t/wayland-color-management/10804 I am
dutch_wolf there) we extensively discussed this and yes this should be
possible
>
> [1] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html
> [2] https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c
>
> Also, there are a few queries to understand the flow, please find below inline:
>
>
> On 2/14/2019 8:16 AM, Sebastian Wick wrote:
>
> This protocol allows clients to attach a color space and rendering
> intent to a wl_surface. It further allows the client to be informed
> which color spaces a wl_surface was converted to on the last presented.
>
> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
> ---
>  Makefile.am                                   |   1 +
>  unstable/color-management/README              |   4 +
>  .../color-management-unstable-v1.xml          | 183 ++++++++++++++++++
>  3 files changed, 188 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 345ae6a..80abc1d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,6 +23,7 @@ unstable_protocols = \
>   unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \
>   unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
>   unstable/primary-selection/primary-selection-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..140f1e9
> --- /dev/null
> +++ b/unstable/color-management/README
> @@ -0,0 +1,4 @@
> +Color management protocol
> +
> +Maintainers:
> +Sebastian Wick <sebastian@sebastianwick.net>
> 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..1615fe6
> --- /dev/null
> +++ b/unstable/color-management/color-management-unstable-v1.xml
> @@ -0,0 +1,183 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="color_management_unstable_v1">
> +
> +  <copyright>
> +    Copyright © 2019 Sebastian Wick
> +    Copyright © 2019 Erwin Burema
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <description summary="color management protocol">
> +    This protocol provides the ability to specify the color space
> +    of a wl_surface. If further enumerates the color spaces currently
> +    in the system and allows to query feedback about which color spaces
> +    a wl_surface was converted to on the last present.
> +    The idea behind the feedback system is to allow the client to do color
> +    conversion to a color space which will likely be used to show the surface
> +    which allows the compositor to skip the color conversion step.
> +  </description>
> +
> +  <interface name="zwp_color_manager_v1" version="1">
> +    <description summary="color manager">
> +      The color manager is a singleton global object that provides access
> +      to outputs' color spaces, let's you create new color spaces and attach
> +      a color space to surfaces.
> +    </description>
> +
> +    <enum name="render_intent">
> +      <description summary="render intent">
> +        render intents
> +      </description>
> +      <entry name="absolute" value="1"/>
> +      <entry name="relative" value="2"/>
> +      <entry name="perceptual" value="3"/>
> +      <entry name="saturation" value="4" />
> +    </enum>
> +
> +    <enum name="well_known_color_space">
> +      <description summary="well-known color spaces">
> +        Well-known color spaces
> +      </description>
> +      <entry name="none" value="0" summary="no known color space" />
> +      <entry name="sRGB" value="1" summary="sRGB color space" />
> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> +      <entry name="rec2020" value="4" summary="rec2020" />
> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)" />
> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve (HDR)" />
> +    </enum>
> +
> +    <enum name="error">
> +      <description summary="fatal color manager errors">
> +        These fatal protocol errors may be emitted in response to
> +        illegal color management requests.
> +      </description>
> +      <entry name="invalid_icc_profile" value="0" summary="invalid ICC profile"/>
> +    </enum>
> +
> +    <request name="set_color_space">
> +      <description summary="set the color space of a surface">
> +        Set the color space of a surface. The color space is double buffered,
> +        and will be applied at the time wl_surface.commit of the corresponding
> +        wl_surface is called.
> +
> +        The render intent gives the compositor a hint what to optimize for
> +        in color space conversions.
> +
> +        If a surface has no color space set, sRGB and an arbitrary render
> +        intent will be assumed.
> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
> +      <arg name="render_intent" type="uint" enum="render_intent"/>
> +    </request>
> +
> +    <request name="color_space_feedback">
> +      <description summary="color space feedback">
> +        Request color space feedback for the current content submission
> +        on the given surface. This creates a new color_space_feedback
> +        object, which will deliver the feedback information once. If
> +        multiple color_space_feedback objects are created for the same
> +        submission, they will all deliver the same information.
> +
> +        For details on what information is returned, see the
> +        color_space_feedback interface.
> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="feedback" type="new_id" interface="zwp_color_space_feedback_v1"/>
> +    </request>
> +
> +    <request name="color_space_from_icc">
> +      <description summary="create a color space from an ICC profile">
> +        Create a color space from an ICC profile. Only three channel
> +        profiles are allowed.
> +      </description>
> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
> +      <arg name="icc" type="fd"/>
> +    </request>
> +
>
>
> If I understand it correctly,
> the client first sends a request for getting color-space for an icc file, receives the color_space interface.
> If we can add the surface in this requests, it can be tied to the color-space interface, and later set color_space,
> without the surface.
>
> You have declared some of the color-space as well known, do you think it will be useful to also let the
> client get the color_space interface, based on the well-known color-space.?
> Server on the other hand can have already built objects from the standard icc files, the interfaces of
> which can be passed to the client.
>
> +    <event name="color_space_added">
> +      <description summary="color space added">
> +        Send after binding or when a new color space is added to the system.
> +      </description>
> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
> +    </event>
> +  </interface>
> +
> +  <interface name="zwp_color_space_v1" version="1">
> +    <description summary="a color space">
> +      A color space can be attached to a wl_surface and sends
> +      information like the ICC profile to let the client perform color
> +      correction.
> +    </description>
> +
> +    <event name="information">
> +      <description summary="color space information">
> +        Information describing the color space.
> +
> +        The icc argument contains a fd to the corresponding ICC profile.
> +        well-known can be used to easily identify a color-space.
> +
> +        A color space can be associated with a wl_output.
> +      </description>
> +      <arg name="icc" type="fd"/>
> +      <arg name="well-known" type="uint" enum="well_known_color_space"/>
> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
> +    </event>
> +
>
>
> When will this event be generated, should there be a request from a client via the color_space interface
> for the information? Will events be sent for each output, the surface is displayed on?
>
> +    <event name="removed">
> +      <description summary="color space removed">
> +        This event is sent when the color space is removed from the system.
> +        When this event is received, the client must destroy the object.
> +      </description>
> +    </event>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the color space object">
> +      Destroy the color_space object.
> +      </description>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_color_space_feedback_v1" version="1">
> +    <description summary="color space feedback">
> +      The surface content was converted to a number of color spaces
> +      on the last content update. They get listed in decreasing order
> +      of importance by the converted event.
> +      Once a color_space_feedback object has delivered a done
> +      event it is automatically destroyed.
> +    </description>
> +
> +    <event name="converted">
> +      <description summary="color space conversion">
> +        The surface was converted to a color space.
> +      </description>
> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
> +    </event>
> +
>
>
> So a client with a surface, will receive a series of these events for its surface, whenever the
> color space conversion takes place for that surface?
> Why do we need this interface, can the color_manager be used to send these events?
>
> Thanks & Regards,
> Ankit
>
> +    <event name="done">
> +      <description summary="done listing color space conversions">
> +        All color space conversion have been listed.
> +      </description>
> +    </event>
> +  </interface>
> +
> +</protocol>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, 14 Feb 2019 at 16:38, Sebastian Wick
<sebastian@sebastianwick.net> wrote:
>
> Thanks. I don't really know about all the standards so I'll just trust
> you on this.
>

These are correct suggestions and do improve the readability by a lot
> On 2019-02-14 05:47, Chris Murphy wrote:
> > On Wed, Feb 13, 2019 at 7:55 PM Sebastian Wick
> > <sebastian@sebastianwick.net> wrote:
> >
> >
> >> +      <entry name="absolute" value="1"/>
> >
> > I suggest ICC spec language.  'ICC-absolute colorimetric'
> >
> >> +      <entry name="relative" value="2"/>
> >
> > 'media-relative colorimetric'
> >
> >
> >> +      <entry name="none" value="0" summary="no known color space" />
> >
> > I think this is 'deviceRGB' although it could be 'unknown'.
> > Practically, it could only be unknown if the values aren't being
> > displayed or output anywhere. The instant RGB values are displayed
> > anywhere, the color space is knowable, therefore it's at least
> > deviceRGB. But unknown is also consistent with EXIF.
> >
> > And 'color space' can be assumed.
> >
> >> +      <entry name="sRGB" value="1" summary="sRGB color space" />
> >
> > Summary probably should be 'sRGB IEC61966-2.1' and again 'color space'
> > can be assumed.
> >
> >> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> >
> > Summary probably should be 'Adobe RGB (1998)'
> >
> >> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> >
> > DCI-P3
> > But there are three, so it needs to be specific which one or define
> > all three. And there's a variant, which is 'Display P3' from Apple,
> > which starts out being defined with DCI-P3 D65 but uses a tone
> > response curve defined by the sRGB curve.
> >
> >
> >> +      <entry name="rec2020" value="4" summary="rec2020" />
> >
> > Probably the summary should be 'ITU-R BT.2020 for UHDTV' same for
> > below.
> >
> >> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq
> >> curve (HDR)" />
> >> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG
> >> curve (HDR)" />
> >
> > It's reasonable to add 'ITU-R BT.709 for HDTV' or Rec. 709 since
> > that's used today still.
> >
> >
> > --
> > Chris Murphy
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Thu, Feb 14, 2019 at 2:27 AM Philipp Zabel <p.zabel@pengutronix.de> wrote:
>
> In the Kernel, AdobeRGB has been replaced with opRGB. Should this be
> name="opRGB", summary="opRGB IEC 61966-2-5"?

opRGB and Adobe RGB (1998) are different color image encodings, and
they apply to different use cases. They strictly speaking are not
interchangeable even if the error resulting from substitution is
small.

http://www.color.org/chardata/rgb/adobergb.xalter
http://www.color.org/chardata/rgb/oprgb.xalter

A color image encoding includes color space, reference viewing
condition, and reference medium. The ICC profile might include tags
for the last two items, optionally, but there's no practical way for
the profile or the color management system to enforce them: it can't
make your display brighter or darken the room. The human is expected
to do that enforcement.

And just because many humans do not even try to approximate reference
viewing conditions or medium, doesn't mean it's OK for an automated
system or an operating system to substitute opRGB for Adobe RGB (1998)
as if they are the same thing. They aren't.

The opRGB use case is for camera encodings going forward. It's not
intended to automatically/transparently/silently substitute opRGB for
existing Adobe RGB (1998) images. You could say, we have nothing to do
with the reference condition or medium, so we actually can do that
substitution! I think that's a slippery slope. And you definitely
cannot get away with it in an HDR world. So my suggestion is to treat
these things as what they are: color image encodings. That's what's
meant by the name, not merely the color space.

And actually, it's probably best to use the following reference for
the name (short name) and definition (summary). And it's also sane to
include all of the listed color image encodings, in this proposal.

http://www.color.org/chardata/rgb/rgb_registry.xalter


--
Chris Murphy
On Thu, Feb 14, 2019 at 5:25 AM Sharma, Shashank via wayland-devel
<wayland-devel@lists.freedesktop.org> wrote:
>
> Well, REC2020 with HLG/PQ curves are not different color spaces, but they are the same color space with different non-linear curves. The colorspace here still remains BT2020 and its primaries are still the same, it's just that the encoding is being done using different curves.

ITU-R BT.2020 is a color image encoding, and that encapsulates color
space primaries, tone response curve (often defined as a gamma
function), white luminance, black luminance, reference viewing
conditions, and reference medium. You can't really separate all of
these things, and their interplay. If you do, you end up with a lot of
the confusion seen in desktop computing color management over the past
20+ years, which is WTF why doesn't it work? Oh, my viewing conditions
and your viewing conditions are not only not standard, but they're
also different from each other.

If BT2020 is a color space, and BT2100 is a color space, you end up
effectively saying BT2020 and BT2100 are the same just because their
primaries are the same. That's clearly wrong. So I think it's best to
not call them color spaces.

Whereas if you say BT.2020 and BT.2100 are different color image
encodings which so happen to share the same primaries, that's more
clear. The rest of those specs matter a lot.

There is a certain vagueness in what is a color space in ordinary
vernacular that even technical color people mess up all the time for
expediency; I'm willing to bet there is a canonical definition in
something like ISO TC 37, but I don't have a copy of that handy. So
anyway, what I try to do is refer to a specification or standard as a
color image encoding. And then specifically to its constituent parts
unambiguously.

I think some confusion with color space as a term comes from the
chromaticity diagram which is a 2D construction, so some people mean
color space to only refer to primaries. Where others think of color
space as a volume, because they grab an ICC profile and do a 3D plot.
So they're thinking in terms other than just primaries, they're
including cap Y (as in CIE xyY). But cap Y comes in unscaled and
scaled flavors. That matters too.

Consider two displays side by side, one with white luminance at 100
nits and another 1000 nits. The ICC profile for those displays will
say their whites are L* 100. If you do a 3D gamut plot of otherwise
identical displays using their ICC profiles, they will be identical.
So what's that about? L* is not luminance, it's lightness, it's
relative to a reference white. What is the reference white? Aha! A
display's profile always considers the display's white point and
luminance as the reference white, which is why every display profile
claims 255,255,255 RGB is L* 100. If we had an absolute luminance
mechanism where the profile could define luminance and actually cause
the brightness knob to move on everyone's displays, we'd have done
that. Maybe. OK no because we need other things like reliable viewing
condition sensors and integrated color appearance models and a new ICC
spec that makes necessary information to do these things actually
required. There's literally no requirement to put absolute luminance
in any device profile. It is optional, however. The tag exists and is
standardized, it's just not required.

OK so the mismatch between my display's white luminanance (display
reference white if you will), and the reference white for the
specification I'm using, can be expected to result in disappointment.
Which is why we try to follow standards as much as possible and where
we can't, we have to have agreement among all the people we work with
*how* we deviate from the standards. If we don't all have the same
conditions, we're going to have different rendering experiences.

And that is the long version on why 'color image encoding' as a full
encapsulating term of what's really important, is the ball to keep our
eye on, not just color spaces.


Chris Murphy
On Thu, 14 Feb 2019 03:46:21 +0100
Sebastian Wick <sebastian@sebastianwick.net> wrote:

> This protocol allows clients to attach a color space and rendering
> intent to a wl_surface. It further allows the client to be informed
> which color spaces a wl_surface was converted to on the last presented.
> 
> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>

Hi Sebastian,

thank you very much for working on this!

It would have been nice if you referred to Neils' proposal and maybe
compared this to that, especially if something here was modelled after
Neils' proposal.

Comments inline.

> ---
>  Makefile.am                                   |   1 +
>  unstable/color-management/README              |   4 +
>  .../color-management-unstable-v1.xml          | 183 ++++++++++++++++++
>  3 files changed, 188 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 345ae6a..80abc1d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,6 +23,7 @@ unstable_protocols =								\
>  	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
>  	unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
>  	unstable/primary-selection/primary-selection-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..140f1e9
> --- /dev/null
> +++ b/unstable/color-management/README
> @@ -0,0 +1,4 @@
> +Color management protocol
> +
> +Maintainers:
> +Sebastian Wick <sebastian@sebastianwick.net>
> 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..1615fe6
> --- /dev/null
> +++ b/unstable/color-management/color-management-unstable-v1.xml
> @@ -0,0 +1,183 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="color_management_unstable_v1">
> +
> +  <copyright>
> +    Copyright © 2019 Sebastian Wick
> +    Copyright © 2019 Erwin Burema
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <description summary="color management protocol">
> +    This protocol provides the ability to specify the color space
> +    of a wl_surface. If further enumerates the color spaces currently
> +    in the system and allows to query feedback about which color spaces
> +    a wl_surface was converted to on the last present.
> +    The idea behind the feedback system is to allow the client to do color
> +    conversion to a color space which will likely be used to show the surface
> +    which allows the compositor to skip the color conversion step.
> +  </description>
> +
> +  <interface name="zwp_color_manager_v1" version="1">
> +    <description summary="color manager">
> +      The color manager is a singleton global object that provides access
> +      to outputs' color spaces, let's you create new color spaces and attach
> +      a color space to surfaces.
> +    </description>

This interface is missing the destroy request.

> +
> +    <enum name="render_intent">
> +      <description summary="render intent">
> +        render intents
> +      </description>
> +      <entry name="absolute" value="1"/>
> +      <entry name="relative" value="2"/>
> +      <entry name="perceptual" value="3"/>
> +      <entry name="saturation" value="4" />
> +    </enum>
> +
> +    <enum name="well_known_color_space">
> +      <description summary="well-known color spaces">
> +        Well-known color spaces

Is a compositor required to send zwp_color_space_v1 objects for all of
these always?

Is the intention here that the compositor sends zwp_color_space_v1
objects for all those it happens to have the ICC profile at hand, and
if a client wants to use a yet another profile which is listed in this
enum, it still needs to provide it as an ICC profile file because the
compositor otherwise could not interpret it?

What if no output nor the compositor itself uses a profile listed here,
but it is still available to the compositor? E.g. sRGB when the
compositor only uses device specific profiles for all outputs and uses
something else as the blending/preferred color space?

> +      </description>
> +      <entry name="none" value="0" summary="no known color space" />
> +      <entry name="sRGB" value="1" summary="sRGB color space" />
> +      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
> +      <entry name="DCI-3P" value="3" summary="DCI-3P" />
> +      <entry name="rec2020" value="4" summary="rec2020" />
> +      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)" />
> +      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve (HDR)" />

Have you done a compile test with this? I would assume the dash with
produce illegal C. Names should be limited to the allowed C symbol
names.

It seems wayland-protocols doesn't actually try to compile the
resulting C code.

> +    </enum>
> +
> +    <enum name="error">
> +      <description summary="fatal color manager errors">
> +        These fatal protocol errors may be emitted in response to
> +        illegal color management requests.
> +      </description>
> +      <entry name="invalid_icc_profile" value="0" summary="invalid ICC profile"/>
> +    </enum>
> +
> +    <request name="set_color_space">
> +      <description summary="set the color space of a surface">
> +        Set the color space of a surface. The color space is double buffered,
> +        and will be applied at the time wl_surface.commit of the corresponding
> +        wl_surface is called.
> +
> +        The render intent gives the compositor a hint what to optimize for
> +        in color space conversions.
> +
> +        If a surface has no color space set, sRGB and an arbitrary render
> +        intent will be assumed.
> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
> +      <arg name="render_intent" type="uint" enum="render_intent"/>

The same comments as to Neils: this is one way to design this. Another
is to make the additional interface a new object which allows you to
hook up to the destruction of that object for resetting to original
state.

What happens when the zwp_color_space_v1 object has already emitted the
'removed' event, but the client has not seen it yet and issues this
request?

What happens with the surface, if the zwp_color_space_v1 object is
destroyed after this request?

What happens with the surface, if the zwp_color_manager_v1 object is
destroyed after this request?

> +    </request>
> +
> +    <request name="color_space_feedback">
> +      <description summary="color space feedback">
> +        Request color space feedback for the current content submission
> +        on the given surface. This creates a new color_space_feedback
> +        object, which will deliver the feedback information once. If
> +        multiple color_space_feedback objects are created for the same
> +        submission, they will all deliver the same information.
> +
> +        For details on what information is returned, see the
> +        color_space_feedback interface.

With this, there is a built-in assumption that the conversions happen
just once per content submission. I don't think that holds. The same
frame can be used repeatedly until the client provides a new one.
During that time, the window may move to another output or something
else changes in the compositor that changes what conversions were made
on latter repaints. The compositor's preferred color space is something
that can change at any time, not only when the client updates.

It might be more suitable to instead formulate this as an extension
object to wl_surface, that would deliver an event every time the
compositor's preferred color space changes. You could also put the
set_color_space request into that extension object and drop the
wl_surface argument.

> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="feedback" type="new_id" interface="zwp_color_space_feedback_v1"/>
> +    </request>
> +
> +    <request name="color_space_from_icc">
> +      <description summary="create a color space from an ICC profile">
> +        Create a color space from an ICC profile. Only three channel
> +        profiles are allowed.

We already have pixel formats which have up to three color channels
plus alpha. Necessarily the ICC profile must agree with the pixel
format's number of color channels. Is that not a sufficient and
necessary restriction rather than just three channels?

> +      </description>
> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
> +      <arg name="icc" type="fd"/>

I think with all fds, there should be at least length of the payload,
since this is something to be mmapped, not a pipe. Right?

Moreover, it would be good to define already here for every fd in the
protocols how they should be expected to be used by the receiver:
mmapped as read-only, with seals allowed but not required. The file
size must not be changed to smaller than the communicated size. The
sender of the fd must not change the contents after sending the fd.

> +    </request>
> +
> +    <event name="color_space_added">
> +      <description summary="color space added">
> +        Send after binding or when a new color space is added to the system.
> +      </description>
> +      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>

A server-created object. This seems innocent enough, but if we look at
zwp_color_space_v1 interface, it defines an event to be sent
immediately the object is created and that event carries even a fd.

This could potentially result in a big flurry of events and fds every
time a client creates a zwp_color_manager_v1 object.

Was this event supposed to deliver all existing color space definitions
on zwp_color_manager_v1 creation automatically?

Is this sent for all color spaces added by clients as well
(color_space_from_icc request)? If yes, I think that has potential to
become denial-of-service attack vector. A malicious client adding a ton
of color spaces could easily cause all new clients to disconnect when
the compositor send buffer overflows on creating a zwp_color_manager_v1
object. It is even more prone because the initial events will carry a
fd per profile, and the number of fds is much more limited than
messages.

The sending also cannot be done in pieces, because there is currently
no way to freeze a request processing in libwayland. If you wanted to
send in pieces, that would have to be built in to the protocol
specification here in the form of a "done" event.

> +    </event>
> +  </interface>
> +
> +  <interface name="zwp_color_space_v1" version="1">

Chris had some good comments on terminology. Is "color space" correct
here? "Color image encoding"?

I think the terminology needs to follow what color management
professionals use. Otherwise they will be confused and misinterpret
things, while the rest of us who learn these for the first time are
fine with any sufficiently unique terms and blissfully ignorant of the
details.

> +    <description summary="a color space">
> +      A color space can be attached to a wl_surface and sends
> +      information like the ICC profile to let the client perform color
> +      correction.
> +    </description>
> +
> +    <event name="information">
> +      <description summary="color space information">
> +        Information describing the color space.
> +
> +        The icc argument contains a fd to the corresponding ICC profile.
> +        well-known can be used to easily identify a color-space.
> +
> +        A color space can be associated with a wl_output.
> +      </description>
> +      <arg name="icc" type="fd"/>
> +      <arg name="well-known" type="uint" enum="well_known_color_space"/>
> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>

Also argument names should be valid C symbol names I believe. Dash is
invalid.

I think this event needs to be split into three:

- fd and file size, to be sent only if the client is actually
  interested in it. Wouldn't clients just ignore most of the ICC files
  and use just the few that they actually need? The fd might not even
  be necessary at all if well_known is set, right?

- well_known, but sent only if there actually is a matching value, no
  need to send "none".

- zero/one or more outputs, can't the same color space apply to
  multiple outputs? Most likely if the outputs are not actually
  calibrated but use either the standard sRGB assumption or maybe an
  ICC profile from then vendor rather than individually measured.

Btw. we're going to need multiple output events in any case, because
one client can bind the same wl_output global multiple times, producing
multiple wl_output objects all referring to the same output. I believe
the usual case when that happens is that the client is using libraries
that independently bind to wl_outputs. The compositor cannot know which
wl_output the client expects to see with the output event, so the
compositor must send output events for all of them.

Another problem with the wl_output argument here is that you implicitly
require clients to bind to wl_outputs before they bind to
zwp_color_manager_v1. Otherwise the clients do not have a wl_output
object the compositor could use in the event argument, and the client
will miss the association with an output. This could be solved by
delivering the color space event from an extension object explicitly
created for a wl_output.

> +    </event>
> +
> +    <event name="removed">
> +      <description summary="color space removed">
> +        This event is sent when the color space is removed from the system.
> +        When this event is received, the client must destroy the object.

"Removed from the system" sounds ambiguous. What does it mean? Probably
something to do with the color spaces registered with the compositor
somehow?

Does this have any consequences to e.g. wl_surfaces where the color
space was attached to? Or outputs?

> +      </description>
> +    </event>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the color space object">
> +	      Destroy the color_space object.

The same question: does this have any consequences to e.g. wl_surfaces
where the color space was attached to? Or outputs?

> +      </description>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_color_space_feedback_v1" version="1">
> +    <description summary="color space feedback">
> +      The surface content was converted to a number of color spaces
> +      on the last content update. They get listed in decreasing order
> +      of importance by the converted event.

What is the use case for delivering a list of color spaces, rather than
just one the compositor would have preferred? How would a client ever
pick or use anything but the first one?

> +      Once a color_space_feedback object has delivered a done
> +      event it is automatically destroyed.
> +    </description>
> +
> +    <event name="converted">
> +      <description summary="color space conversion">
> +        The surface was converted to a color space.
> +      </description>
> +      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
> +    </event>
> +
> +    <event name="done">
> +      <description summary="done listing color space conversions">
> +        All color space conversion have been listed.
> +      </description>
> +    </event>
> +  </interface>
> +
> +</protocol>

Thanks,
pq
Sebastian Wick wrote:
> A color space consits of three primaries, the white point and the EOTF/OETF.

That's not true in general. An RGB colorspace can be described (and is
describable using ICC profiles) in ways that cannot be decomposed
into 3 primaries and per channel curves, since some devices
are not additive. A cLUT encoding is such a description.

Sharma, Shashank via wayland-devel wrote:
> Well, this is slightly off the chart for me. If I understood this correctly, the cover
> letter talks about the intent is to focus on Colorspace only, but here we are
> differentiating enum values based on their EOTF HDR curve, which is the only difference
> between these three colorspaces. Then why not just mind the colorspace regardless of
> the HDR curve.
> 
> On the other hand, we can accommodate the HDR specific information also, like the EOTF
> curve type, and the HDR metadata type and content for the frame, if we can add some
> additional filed in this same protocol. So the colorspace information will remain the
> same, and the presence of HDR metadata type / content filed can indicate if the current
> frame is HDR BT2020 frame or SDR BT2020 frame.

It is not normal in a color management context to use the term
"colorspace" to refer just to the gamut enclose by 3 additive
primaries, instead it usually encompasses the full multi-dimensional
(i.e. 3 dimensional in the case of RGB devices) response.

ICC profiles encompass a description of a devices color response,
but also typically contain information for the mechanisms to convert
between that colorspace and others (i.e. A2B and B2A tables). For
performance and flexibility reasons, this can and does include various
perceptual and gamut transformations chosen by the profile maker, so
a nominated ICC profile can encompass a variety of treatments or intent
within the formalized ICC Perceptual and Saturation intents. There often
is no formal scheme for such variations, just the name, description and
other notes that come with the profile convey the intention of the maker.

Cheers,
	Graeme Gill.
Pekka Paalanen wrote:

> Is this sent for all color spaces added by clients as well
> (color_space_from_icc request)? If yes, I think that has potential to
> become denial-of-service attack vector. A malicious client adding a ton
> of color spaces could easily cause all new clients to disconnect when
> the compositor send buffer overflows on creating a zwp_color_manager_v1
> object. It is even more prone because the initial events will carry a
> fd per profile, and the number of fds is much more limited than
> messages.

I don't see a case for (source) color profiles uploaded by
a client being visible to other clients. Other clients
don't know what they represent, so can't really
make use of them. It would be a waste of time to even look
for them.

The idea of making standard profiles available to all clients
is a way of not duplicating well understood spaces. These
are usable by all clients because they have understood identifiers
and definitions, and are not going to change while the client is
using them. (Note however that it is possible for an output
profile to change, so ideally there should be a way of a client
being notified of this, so that they can take appropriate
action if they wish).

> Chris had some good comments on terminology. Is "color space" correct
> here? "Color image encoding"?

I suspect different people may mean different things by these.

By my definitions, a colorspace is something that comes
out of, or goes into a color capture or reproduction device,
or something that can be related to device independent color values.

Encoding on the other hand, is a way of representing those
color values in a digital form. So by my definition that
includes reversible transformations such as YCC like encodings,
different bit depths, float vs. integer and ranges (i.e. video range encoding) etc.

I'm not sure if there is a formal definition that can be pointed to.

> - zero/one or more outputs, can't the same color space apply to
>   multiple outputs? Most likely if the outputs are not actually
>   calibrated but use either the standard sRGB assumption or maybe an
>   ICC profile from then vendor rather than individually measured.

Yes, that's the most likely scenario. But all the profiles
(i.e. output profiles, standard profiles, client uploaded
 profiles) should be able to be referred to by a handle or
 object identifier, and that would be what is used to tag
 the output or surface.

Cheers,
	Graeme Gill.