[RFC 0/1] Color manager calibration protocol v1

Mon Apr 15 19:42:47 UTC 2019

On 2019-04-15 21:01, Simon Ser wrote:
> 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.

Yes, thanks.

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

Apparently I really wasn't paying attention when writing this. This
shouldn't be there. The wl_display.sync mechanism should be used to
ensure that all measurements are done in the valid state.

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

With a colorimeter. Write some values that you expect to have a certain
color, read the actual colors, calculate the error.
I'm not sure if that answers your question.

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