[RFC wayland-protocols 1/1] unstable: add color management protocol
Sharma, Shashank
shashank.sharma at intel.com
Thu Feb 14 04:55:32 UTC 2019
Hello Sebastian,
My comments inline.
Regards
Shashank
> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-bounces at lists.freedesktop.org] On
> Behalf Of Sebastian Wick
> Sent: Thursday, February 14, 2019 8:16 AM
> To: wayland-devel at lists.freedesktop.org
> Cc: Sebastian Wick <sebastian at 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 at 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 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list