[RFC 0/1] Color manager calibration protocol v1

[Simon Ser]

On Monday, April 15, 2019 9:30 PM, 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.

This makes sense to me as well. Is there a guarantee that the surface is always
a single solid color?

> Maybe something like this would work:
>
> <?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"/>

Typo: not a 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>

What would this be for?

>      <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

How would the client "measure"?

> 10. if the state changes to invalid in between go to 8
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel