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

[Erwin Burema]

Hi,
On Wed, 13 Mar 2019 at 10:06, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Tue, 12 Mar 2019 17:02:53 +0100
> Erwin Burema <e.burema at gmail.com> wrote:
>
> > 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)
>
> Hi Erwin,
>
> the problem with the alternate color pipeline you proposed is that it
> has two color space transformations. It is the pipeline I originally
> assumed would be needed, but then Graeme and Chris convinced me
> otherwise, and I was happy because it simplified things.
>

That is why we need both pipelines one for the non-critical path in
which case we can alpha blend and one for the critical path in which
case we can only blit. I would like to note that from a color
management view gamma/degamma is also a color transform (a linear
space with the sRGB primaries is not the same thing as sRGB), although
one that is in many cases so easily revertible that we often forget
that this is the case.

> If we have the pipeline with a really separate blending space and need
> two different color space transformations, at least the question of how
> to pick the right intents for each comes up if I understood right.
>

Yeah that is indeed a problem

> Graeme, Chris, what do you think?
>
> Excellent web links by the way!
>

Thanks, Elle Stone did a lot of work regarding color management for
GIMP which she noted down on her site, there is a lot more there that
might be of interest!

Adding to this all I would like to note that although I think that for
the best possible output we need both a  critical and non-critical
color path I personally can live with some wonky alpha transparencies
considering that most of the time those should be limited to effects,
but I would hardly call that every frame perfect ;)

>
> Thanks,
> pq

Regards,

Erwin