[RFC wayland-protocols 1/1] unstable: add color management protocol
Erwin Burema
e.burema at gmail.com
Thu Feb 14 18:04:23 UTC 2019
On Thu, 14 Feb 2019 at 16:39, Sharma, Shashank via wayland-devel
<wayland-devel at lists.freedesktop.org> wrote:
Hi,
>
> 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 12:13 PM
> > To: wayland-devel at 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 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-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 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 ?
> >
> > 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 at lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> 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