[RFC 0/1] Color manager calibration protocol v1

[Erwin Burema]

On Mon, 15 Apr 2019 at 20:30, Sebastian Wick
<sebastian at sebastianwick.net> wrote:
>
> On 2019-04-14 12:57, Erwin Burema wrote:
> > Without a way to calibrate/profile screens an color management
> > protocol looses a lot of its value. So to add this missing feature I
> > wrote the following protocol.
> >
> > The idea is that the calibration/profiling SW only sets the RGB
> > triplet and then the compositor is responsible to draw a rectanglular
> > region on the selected output screen, since not all calibration tools
> > will be at the center of the screen a user should be able to modify
> > the placement of this rectanglular region. Unless specified the
> > monitor profile (if any) should not be applied but the GPU curve
> > should, currently to set a new curve the calibration tool should
> > generate a new ICC profile with the wanted curve in the VCGT tag (I am
> > not sure if this is the best option but would make the most universal
> > one). In the end after profiling the last uploaded ICC could then be
> > saved (although a compositor is not required to honor the request in
> > that case it should send the not saved error). If the compositor
> > doesn't save or the connection with this protocol is broken the
> > compositor should restore previous settings.
> >
> > Currently no support to calibrate HDR screens since this will require
> > direct access (no tonemapping or color correction should happen in the
> > screen, with the potential exception if it is possible to upload
> > custom LUTs to the screen), this will require something like the
> > FREESYN2_GAMMA22 display mode as described here:
> > https://gpuopen.com/using-amd-freesync-2-hdr-color-spaces/ if this is
> > not available a HDR screen should be treated as if it is a rec2020+PQ
> > or HLG since it will do its own compositing+color managing (which
> > might or might not be correct)
> >
> > Erwin Burema (1):
> >   Add color manager calibration protocol v1
> >
> >  .../cm_wayland_calibration.xml                | 106 ++++++++++++++++++
> >  1 file changed, 106 insertions(+)
> >  create mode 100644
> > unstable/color-manager-calibration/cm_wayland_calibration.xml
>
> The requirement to let the user position the patch makes me think that
> using a normal surface in a special mode makes more sense. Maybe
> something like this would work:
>

I have tought about that as well but discarded that for several reasons
1) Will always be a single solid color, so no need for the full
wl_buffer/wl_surface interface
2) Will need to be displayed above anything else, anywhere on the
specified screen (for normal surface this might be a problem for
tiling window managers)
3) Since after the colorimeter/spectrometer has been places and
measuring is begun it shouldn't be touched anymore (so placing is a
setup action, afterwards should be imovable)
4) Needs to be confined to a single output
5) Preferably need to be in display color depth (especially for calibration)

My preffered way to place it would actually be similar to a
screengrabber that allows to grab a section of the screen, where a
user could just select a portion of the screen as "in this area the
measuring device is/will be place", so deciding I wanted to keep
things as simple as possible I decided against using wl_surface. (It
will also get rid of the is_valid events since it should always
display above anything else since it is not a normal surface)

> <?xml version="1.0" encoding="UTF-8"?>
> <protocol name="color_measure_unstable_v1">
>
>    <description summary="color calibration and profiling">
>    </description>
>
>    <interface name="zwp_color_measure_v1" version="1">
>      <description summary="">
>      </description>
>
>      <enum name="measure_mode">
>        <description summary="">
>        </description>
>        <entry name="standard" value="0" summary=""/>
>        <entry name="passthrough" value="1" summary=""/>
>      </enum>
>
>      <request name="get_color_measurement_surface">
>        <description summary="">
>        </description>
>        <arg name="id" type="new_id"
> interface="zwp_color_measure_surface_v1"/>
>        <arg name="surface" type="object" interface="wl_surface"/>
>        <arg name="output" type="object" interface="wl_output"/>
>        <arg name="mode" type="uint" enum="measure_mode"
> interface="wl_output"/>
>      </request>
>
>      <request name="destroy" type="destructor">
>        <description summary="destroy the color measure">
>        </description>
>      </request>
>    </interface>
>
>    <interface name="zwp_color_measure_surface_v1" version="1">
>      <description summary="">
>         The underlying surface has a state which indicates if it is shown on
> the
>         output without further manipulation.
>
>         In particular if the surface is in the state valid with mode standard
> the
>         compositor guarantees that only the color correction pipeline and no
>         "special" effects are applied to the surface.
>
>         In the state valid with mode passthrough the color values of the
> surface are
>         gauranteed to reach the output as is (e.g. no color correction and no
> vcgt
>         LUT gets applied).
>
>         If the state is invalid there is no guarantee how the color values are
>         transformed before reaching the output.
>      </description>
>
>      <enum name="state">
>        <description summary="">
>        </description>
>        <entry name="valid" value="0" summary=""/>
>        <entry name="invalid" value="1" summary=""/>
>      </enum>
>
>      <request name="sync">
>      </request>
>
>      <event name="done">
>      </event>
>
>      <event name="state_changed">
>        <arg name="state" type="uint" enum="state"/>
>      </event>
>
>      <request name="destroy" type="destructor">
>        <description summary="destroy the color measure surface">
>        </description>
>      </request>
>    </interface>
>
> </protocol>
>
>
> I'd imagine the client to do something like this:
>
> 1. create a zwp_color_measure_surface_v1 for the surface and the output
>     to measure in the passthrough mode
> 2. tell the user to position the surface correctly and wait for the
>     state to be valid (for example in gnome shell the state would be
>     invalid when the surface is shown in expose or not shown on the
> output
>     at all)
> 3. calibrate by filling the surface and applying the "vcgt" in software
> 4. profile
> 5. if the state changes to invalid in between go to 2
> 6. create the ICC profile and load it to the compositor via colord
> 7. destroy the interface, create a new one in the standard mode
> 8. wait for the state to be valid (as before)
> 9. measure the colors and check if the profile works as intended
> 10. if the state changes to invalid in between go to 8
>

I would prefer not to depend on colord at least not from the protocol
perspective, I think it would be a great idea if compositors used it
tough!