[RFC wayland-protocols 1/1] unstable: add color management protocol
Erwin Burema
e.burema at gmail.com
Thu Feb 14 18:20:39 UTC 2019
Hi,
On Thu, 14 Feb 2019 at 16:40, Nautiyal, Ankit K via wayland-devel
<wayland-devel at 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 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" />
> + </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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list