[RFC PATCH 1/6] Add colorcorrection protocol

[Bill Spitzak]

Niels Ole Salscheider wrote:
> The color correction protocol allows to attach an ICC profile to a
> surface. It also tells the client about the blending color space and
> the color spaces of all outputs.

As you pointed out, it does look like this has to be done by the 
compositor, because a different color correction has to be applied to a 
surface for each output. Since a surface can appear on more than one 
output simultaneously, and that information is not available to a 
client, the compositor must do this.

> +    <request name="set_profile">
> +      <description summary="set the color profile of a wl_surface">
> +	With this request, the color profile of a wl_surface can be set.
> +	When mode is set to "profile", an ICC profile can be passed in the
> +	"profile_data" argument. In all other cases, "profile_data" is
> +	ignored.
> +	"mode" should only be set to "uncorrected" for fullscreen applications
> +	or applications that really require uncorrected output (e. g. color
> +	profiling tools).
> +      </description>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="mode" type="uint" />
> +      <arg name="profile_data" type="array"/>
> +    </request>

This should be double-buffered: it does not happen until a commit.

I would make the profile be an object, not a block of data, so it can be 
reused easily. (this is in addition to the other discussion of how the 
data is conveyed between client and compositor). The "mode" can be 
eliminated by making special profile objects for each mode.

> +    <event name="blending_space">
> +      <description summary="tell the client what blending space is used">
> +	This event will be sent when the blending space of the compositor
> +	is changed. A client can use this information to output its surface
> +	in the blending space of the compositor so that only one color
> +	transform (from blending to output space) has to be performed by the
> +	compositor. This can result in better performance.
> +      </description>
> +      <arg name="profile_data" type="array"/>
> +    </event>

I don't like this description. There may be a "linear" blending space, 
but the purpose is not to describe some "faster" space. In fact sending 
the buffer as a linear color space may be much slower and look much worse.

A compositor does not have to implement a linear blend by converting the 
source to linear space and building a buffer of linear values. Instead 
it can do it with amazingly crude approximations. For instance replacing 
a+b with sqrt(a^2+b^2) will do a pretty good job of adding two sRGB 
images together, indistinguishable by eye from the accurate result. And 
the source and destination are all in sRGB space.

The reason clients want to know the blending space is because it changes 
how partially-transparent areas, in particular shadows, are stored in 
the source, especially if the client wants to draw internal shadows in 
the buffer that "match", or set the drag&drop cursor to am image that 
actually composites correctly into the drop target.

I suspect also the blending space may vary depending on the surface: it 
may do a subsurface different than a parent (especially for remote 
display), and if overlay planes are used it may change the blending 
space. Maybe it would be sufficient to send this per-surface.