[RFC wayland-protocols v2 0/1] Color Management Protocol

[Pekka Paalanen]

On Thu, 7 Mar 2019 12:37:52 +0100
Erwin Burema <e.burema at gmail.com> wrote:

> Wed Mar 6 17:09:27 UTC 2019 Sebastian Wick :
> >...  
> 
> > 2. The whole pipeline should look something like
> >
> >   [surface cs] -cs conversion-> [output cs] -tone mapping-> [output cs]
> >    -degamma-> [output linear cs] -blending-> [output linear cs] -gamma->
> >    [output cs].
> >
> >    Where some parts can be skipped if e.g. surface cs == output cs or
> >    surface and output are SDR.  
> 
> For expert/pro applications this is probably indeed the pipline
> needed, the only thing that troubles me here is, is that there no
> guarente that an output color space is well behaved so might still
> contain some non-linearities or other issues after the degamma
> process[1], so for non-expert/non-pro stuff that still cares to some
> extent for color a better pipeline might be
> [surface cs] -cs conversion-> [blending scene referred cs] -blending->
> [blending scene referred cs] -tone mapping-> [blending output referred
> cs] -cs conversion-> [output cs]
> Of course since this requires two cs conversion steps this is not
> ideal for anything pro but the only blending operation that is
> guaranteed to be artifact free in output cs is bit blitting which is
> not something we want to limit compositors to.

Hi Erwin,

did you consider that the blending we talk about here is only alpha
blending with alpha in [0, 1] and 1-alpha coefficients and nothing
else? I forget who recently noted that alpha blending shouldn't cause
any problems since mathematically the result cannot exceed the source
space.

Could you elaborate on the potential problems with the proposed
pipeline more?

Do you mean that the degamma mapping computed from the output color
profile might be so far off, that alpha blending would produce a
visibly wrong color on the monitor?

I would lean on taking that risk though, to have support for "pro
applications". People would definitely be upset if "pro apps" were not
properly supported, while alpha blending is usually just for visual
special effects like rounded corners or fade-in/out animations and
other less important window system gimmicks. I also do not see the
latter important enough to warrant implementing both ways in a
compositor.

> 
> > ...  
> 
> > 3. Do the standard color spaces actually improve anything? When the
> >   compositor doesn't have to make them available to clients and they
> >   can't rely on them being available, what's the point? Especially when
> >   displays don't really support standard color spaces most of the time
> >   (according to the EDID).  
> 
> The point (to me at least) is that if a program uses one of the
> default/standard color space we can mostly assume that they are not
> extremely color critical and can use an intermediate blending space,
> anything that renders directly to an output they are displayed on
> should be considered color critical, in which case a compositor should
> follow your proposed pipeline (maybe without degamma/gamma since we
> should be bit blitting by then anyway). Now an alternative to this
> might be to let programs set ICC profiles (RGB ones only of course) in
> which case so long as it is not an output profile it should be fine to
> use a blending space.

I do not think building in such assumptions, that a client that uses a
predefined color space would be somehow less color-critical, is a good
idea.

If there must be a notion of less and more color-critical, they would
need to be exactly defined and explicitly communicated in the protocol.
I suspect defining and implementing such things would be quite
difficult.


Thanks,
pq

> ---
> [1] If that is even possible, although if we run into that case we are
> probably dealing with a cheap consumer monitor that someone has
> calibrated/profiled to get the best out of it
> 
> Kind Regards,
> 
> Erwin Burema
-------------- 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/20190312/aab72236/attachment.sig>