[RFC wayland-protocols 1/1] unstable: add color management protocol
Sharma, Shashank
shashank.sharma at intel.com
Thu Feb 14 12:25:45 UTC 2019
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.
> 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 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