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

[Erwin Burema]

Hi,

Comments inline
On Tue, 12 Mar 2019 at 14:01, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> 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?
>

Yes alpha blending can't exceed color space but can lead to color
artifacts (if you ever edited/created a picture in sRGB and saw some
dark/black borders that is one possible effect)

Some of the problems of blending colors in non-linear spaces are
described here:
https://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html
(not my site, has lots of pictures which hopefully makes the
explanation a bit better)

Theoretically this should be solved by degamma but there is no
guarantee that after that operation a profile is well behaved (see
https://ninedegreesbelow.com/photography/well-behaved-profile.html),
it might be neither withe balanced nor normalized, in which case you
will get similar artifacts as if working in a non-linear space.

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

Yes, see above, also not sure if a degamma is always possible
(especially with LUT based profiles) Graeme Gill can probably give a
more complete answer here. Although this will be a bigger issue on
cheap consumer monitors then expensive pro-ones.


> 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.
>
If you can be sure alpha blending is only used for effects and nothing
else this is an acceptable trade off but blending HDR and non-HDR
content should probably be done in a scene referred color space which
the output one isn't (even if it is degammaed) which means that in
some cases you might need/want the second way anyway, that said
pro-applications that deal with both HDR and non-HDR content should
probably take care of the critical parts of the blending itself and
output in HDR (so only the user interface would then be non-HDR)

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

If you do as you suggest and always blend in output space then indeed
a difference is not needed. I am still not convinced that is a good
idea (at least for anything more then bit blitting) in that case some
way to indicate if something is color critical or not will be needed.

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

Kind Regards

Erwin Burema