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

Fri Mar 1 10:57:29 UTC 2019

On Thu, 28 Feb 2019 20:58:04 +0100
Kai-Uwe <ku.b-list at gmx.de> wrote:

> Am 28.02.19 um 12:37 schrieb Pekka Paalanen:
> > On Thu, 28 Feb 2019 09:12:57 +0100
> > Kai-Uwe <ku.b-list at gmx.de> wrote:
> >  
> >> Am 27.02.19 um 14:17 schrieb Pekka Paalanen:  
> >>> 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>  
> >>>>>>
> >>>>>> +    <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?

...

> >> client developers should never use translucent portions. However the
> >> toolkit or compositor might enforce this, e.g. for window decoration,
> >> that outside translucency would break the app intention.)  
> > I really cannot say, I have no opinion on the matter so far. A
> > compositor could be implemented either way.  
> 
> Perhaps the sub surface in wayland is a means for apps, to express the
> intention of a pass through for colors with hopefully no blending. At
> least Dmitry Kazakov mentioned a concept with similarities for
> implementing display HDR support (Windows) inside Krita (open source
> image editor) canvas.

Hi Kai-Uwe,

I'm afraid sub-surface is not quite that. Sub-surfaces allow separating
the pieces of a window into different buffers, e.g. for a video player:
background and decorations, video, subtitles. The benefit is that the
app punts the combining of these pieces to the compositor, which may
then be able to put the video on a hardware overlay for instance. It
does allow using different color spaces for the different pieces, so
maybe that can be useful.

There is currently no concept to say "please, do not put anything
translucent on top of my window" if that is what you mean.

OTOH, the app's own window's blending vs. not is in quite good control
by the app already: use a pixel format without an alpha channel or mark
areas as opaque (wl_surface.set_opaque_region). The opaque region is an
optimization hint, so it should not affect the outcome if alpha says
opaque, but it can allow compositors to optimize their work.

Even still, a compositor could decide to make the window translucent,
if that is the user's preference. This is actually a part of the
reason why measurement/calibration/characterization windows would need
to be marked explicitly as such, so that the compositor knows to present
it correctly regardless of user preferences and other applications.

> > It is not just about window A with the device link profile, it is
> > window B on top of that whose translucency would be a problem, since
> > window A "forces" the color space to become the output color space
> > before window B can be blended in. Or indeed, having to convert from
> > output space to blending space for blending window B and then back to
> > output space again.  
> 
> That sounds all not simple. But either that whole conversion or
> splitting the affected regions into sub subsurfaces is one of the few
> possibilities I see here.

Yes, this is why the device link profile feature seems problematic to
me. Maybe it would have to be reserved for fullscreened and active
top-most windows that are exclusive on the given output... but that
might be prone to bad user experience: "why are my colors different
when I made the app fullscreen?" in case the app is not very careful in
communicating that expectation.

Also, if a compositor was implemented strictly correctly, device link
profiles should not produce any different result. From that point of
view I'm getting the feeling that the design would be optimizing for
faulty compositors. It could be used for testing compositor correctness
though.

> >>> Does that even make any difference if the output space was linear at
> >>> blending step, and gamma was applied after that?    
> >> Interesting. There came the argument that the complete graphics pipeline
> >> should be used for measuring the device for profile generation. So, if
> >> linear (blending) space is always shown to applications and measurement
> >> tools, then that should be profiled and fine. Anyway, a comment from
> >> Graeme Gill would be welcome, on how to profile in linear space? As a
> >> side effect, wayland/OpenGL can do the PQ/HLG decoding afterwards,
> >> without the ICC profiling tool have to worry about. I guess all the
> >> dynamic HDR features will more or less destroy the static connection of
> >> input values to display values. The problem for traditional color
> >> management is that linearisation, or as others spell it, gamma transfer
> >> will be a very late step inside the monitor to do correctly. So one
> >> arising question is, how will the 1D graphic card LUT (VCGT) be
> >> implemented? With VCGT properly supported, the output profile could
> >> still work on sufficiently well prepared device behaviour.
> >>
> >> Here a possible process chain:
> >>
> >> * app buffer (device link for proofing or source profile) ->[ICC
> >> conversion in compositor]->
> >>
> >> * blending space (linear) ->[gamma 2.2]->
> >>
> >> * calibration protocol ->[1D calibration (VCGT)]->
> >>
> >> * [encoding for on-the-wire values PQ/...]->
> >>
> >> * transfer to device
> >>
> >> The calibration protocol is there for completeness.  
> > I'm happy to have manged to say something interesting! :-)  
> 
> Hehe ;-) Personally I am very thankful for you all to take part in this
> discussions and that over years.

Thank *you*,
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/20190301/b573acd2/attachment.sig>