On Tue, 12 Mar 2019 17:02:53 +0100 Erwin Burema <[email protected]> wrote:
> Hi, > > Comments inline > On Tue, 12 Mar 2019 at 14:01, Pekka Paalanen <[email protected]> wrote: > > > > On Thu, 7 Mar 2019 12:37:52 +0100 > > Erwin Burema <[email protected]> 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
pgps2vh6WBC3o.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
