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

[Pekka Paalanen]

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.

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.

Graeme, Chris, what do you think?

Excellent web links by the way!


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/20190313/88152758/attachment.sig>