[RFC wayland-protocols v2 1/1] Add the color-management protocol

Wed Feb 27 13:17:07 UTC 2019

On Tue, 26 Feb 2019 18:56:06 +0100
Kai-Uwe <ku.b-list at gmx.de> wrote:

> Am 26.02.19 um 16:48 schrieb Pekka Paalanen:
> > On Sun, 22 Jan 2017 13:31:35 +0100
> > Niels Ole Salscheider <niels_ole at salscheider-online.de> wrote:
> >  
> >> Signed-off-by: Niels Ole Salscheider <niels_ole at salscheider-online.de>  
> 
> > My failing is that I haven't read about what ICC v4 definition actually
> > describes, does it characterise content or a device, or is it more
> > about defining a transformation from something to something without
> > saying what something is.  
> 
> ICC v4 is a specification from 2010 and became in the same year ISO
> 15076-1:2010. Both specs are technically identical. The standard
> describes the content of a color profile format and gives some hints on
> how to handle color transforms. The v4 ICC profiles, as previous ICC v2
> profiles too, can describe device color characteristics in relation to a
> reference color space (ProfileConnectionSpace PCS CIE*XYZ or CIE*Lab).
> This most often variant is used for color space characterisation, e.g.
> sRGB or device characterisation (monitors, cameras, ...). With this
> variant the compositor takes over responsibility and uses intelligence
> to combine the input source profile with perhaps effect profiles, for
> white point adjustment, red light reduction etc... and a final output
> profile into one color transform. The transform is then applied as 3D
> texture/shader depending on the actual compositor implementation.
> 
> A ICC profile class variant, called device link profiles, can describe a
> color conversion without a reference color space, e.g. RGB->RGB. More below
> 

...

> >> +    <request name="set_device_link_profile">
> >> +      <description summary="set a device link profile for a wl_surface and wl_output">
> >> +        With this request, a device link profile can be attached to a
> >> +        wl_surface. For each output on which the surface is visible, the
> >> +        compositor will check if there is a device link profile. If there is one
> >> +        it will be used to directly convert the surface to the output color
> >> +        space. Blending of this surface (if necessary) will then be performed in
> >> +        the output color space and after the normal blending operations.  
> > Are those blending rules actually implementable?
> >
> > It is not generally possible to blend some surfaces into a temporary
> > buffer, convert that to the next color space, and then blend some more,
> > because the necessary order of blending operations depends on the
> > z-order of the surfaces.
> >
> > What implications does this have on the CRTC color processing pipeline?
> >
> > If a CRTC color processing pipeline, that is, the transformation from
> > framebuffer values to on-the-wire values for a monitor, is already set
> > up by the compositor's preference, what would a device link profile
> > look like? Does it produce on-the-wire or blending space?
> >
> > If the transformation defined by the device link profile produced
> > values for the monitor wire, then the compositor will have to undo the
> > CRTC pipeline transformation during composition for this surface, or it
> > needs to reset CRTC pipeline setup to identity and apply it manually
> > for all other surfaces.
> >
> > What is the use for a device link profile?  
> 
> A device link profile is useful to describe a transform from a buffer to
> a match one specific output. Device links can give a very fine grained
> control to applications to decide what they want with their colors. This
> is useful in case a application want to circumvent the default gamut
> mapping optimise for each output connected to a computer or add color
> effects like proofing. The intelligence is inside the device link
> profile and the compositor applies that as a dump rule.

Hi Kai-Uwe,

right, thank you. I did get the feeling right on what it is supposed to
do, but I have hard time imagining how to implement that in a compositor
that also needs to cater for other windows on the same output and blend
them all together correctly.

Even without blending, it means that the CRTC color manipulation
features cannot really be used at all, because there are two
conflicting transformations to apply: from compositor internal
(blending) space to the output space, and from the application content
space through the device link profile to the output space. The only
way that could be realized without any additional reverse
transformations is that the CRTC is set as an identity pass-through,
and both kinds of transformations are done in the composite rendering
with OpenGL or Vulkan.

If we want device link profiles in the protocol, then I think that is
the cost we have to pay. But that is just about performance, while to
me it seems like correct blending would be impossible to achieve if
there was another translucent window on top of the window using a
device link profile. Or even worse, a stack like this:

window B (color profile)
window A (device link profile)
wallpaper (color profile)

If both windows have translucency somewhere, they must be blended in
that order. The blending of window A cannot be postponed after the
others.

I guess that implies that if even one surface on an output uses a
device link profile, then all blending must be done in the output color
space instead of an intermediate blending space. Is that an acceptable
trade-off?

Does that even make any difference if the output space was linear at
blending step, and gamma was applied after that?

> 
> > If the client says the content is according to a certain specification
> > (set_color_profile) and the compositor combines that with the output's
> > color profile to produce the on-the-wire pixel values, how would
> > setting a device link profile produce something different?
> >  
> >> +        The device link profile is applied after the next wl_surface.commit
> >> +        request.  
> > "The device link profile is double-buffered state, see
> > wl_surface.commit."
> >  
> >> +      </description>
> >> +      <arg name="surface" type="object" interface="wl_surface"
> >> +           summary="the surface for which the device link profile should be used" />
> >> +      <arg name="output" type="object" interface="wl_output"
> >> +           summary="the output for which the device link profile was created" />
> >> +      <arg name="device_link_profile" type="object"
> >> +           interface="zwp_color_profile_v1" summary="the device link profile" />
> >> +    </request>

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190227/55372228/attachment.sig>