RE: Pre-meeting Thoughts on HDR Canvas

HDR crossfade issue came up re live video production mixing console where crossfades are done in the vision mixing console  in the non-linear (gamma for SDR) domain. The crossfade is not a simple linear function but is well controlled with a stored function, e.g. assuming fade parameter ‘a’ goes from 0 to 1, crossfade from Video 1 to Video 2 is programmed not as:

Vout=(1-a) V1 + a V2
But as:
Vout = f(1-a) V1 + f(a) V2

So the function f defines the look of the crossfade. Using an f defined for SDR crossfades of course produced a different looking crossfade for PQ. The solution was to load in a different table lookup for the crossfade function f. So if you can tolerate a table lookup for f(a) you can have  any crossfade characteristic that you like.

From: Lars Borg <borg@adobe.com>
Sent: Wednesday, January 27, 2021 2:30 PM
To: Leonard Rosenthol <lrosenth@adobe.com>; Justin Novosad <junov@google.com>; Chris Lilley <chris@w3.org>
Cc: public-colorweb@w3.org
Subject: Re: Pre-meeting Thoughts on HDR Canvas

And let’s not forget that most blend modes support only the range 0 – 1.
That’ll be interesting in HDR mode.

Lars

From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Date: Wednesday, January 27, 2021 at 12:25 PM
To: Lars Borg <borg@adobe.com<mailto:borg@adobe.com>>, Justin Novosad <junov@google.com<mailto:junov@google.com>>, Chris Lilley <chris@w3.org<mailto:chris@w3.org>>
Cc: "public-colorweb@w3.org<mailto:public-colorweb@w3.org>" <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Subject: Re: Pre-meeting Thoughts on HDR Canvas

I would say that pretty much every content authoring tool – be it graphics (Photoshop, Inkscape, Scribus) or documents (MSOffice, GDocs, PDF, etc.) uses gamma/non-linear blending – though also in SDR.  To change that in the web space (at least for SDR content) would also require a change of all of those authoring tools or users won’t be able to author content that matches.

I do agree, however, that in the context on HDR content it may well make sense to consider alternatives since the authoring isn’t there yet…. Provided that we fully describe a mixed SDR/HDR stack and how compositing would work in such a scenario – especially when multiple colorspaces are also involved…

Leonard

From: Lars Borg <borg@adobe.com<mailto:borg@adobe.com>>
Date: Wednesday, January 27, 2021 at 2:23 PM
To: Justin Novosad <junov@google.com<mailto:junov@google.com>>, "chris@w3.org<mailto:chris@w3.org>" <chris@w3.org<mailto:chris@w3.org>>
Cc: "public-colorweb@w3.org<mailto:public-colorweb@w3.org>" <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Subject: Re: Pre-meeting Thoughts on HDR Canvas
Resent-From: <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Resent-Date: Wednesday, January 27, 2021 at 2:23 PM

It is easy to assume that blending in gamma space is always undesirable.
History tells a different story. Blending in non-linear space is common.
For example, in Photoshop you can select to blend in linear or non-linear space.
It’s a creative choice. It seems most users select the non-linear option.
AFAIK video fades are typically in code space, not linear space.
So it seems we should retain this option.

Lars

From: Justin Novosad <junov@google.com<mailto:junov@google.com>>
Date: Wednesday, January 27, 2021 at 7:59 AM
To: Chris Lilley <chris@w3.org<mailto:chris@w3.org>>
Cc: "public-colorweb@w3.org<mailto:public-colorweb@w3.org>" <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Subject: Re: Pre-meeting Thoughts on HDR Canvas
Resent-From: <public-colorweb@w3.org<mailto:public-colorweb@w3.org>>
Resent-Date: Wednesday, January 27, 2021 at 7:59 AM

Thanks Chris for correcting me.

I realize this is an old problem, but I think that adding HDR capabilities to canvas risks exacerbating it greatly because we will end up with inconsistent blending and gradient interpolation based on the canvas's working profile.
For example, if a hypothetical app selects a canvas working profile to match the output device's capabilities, these behavior discrepancies risk being perceived as bugs and will be unpleasant to work around for web developers.

On Wed, Jan 27, 2021 at 12:46 PM Chris Lilley <chris@w3.org<mailto:chris@w3.org>> wrote:

On 2021-01-27 18:32, Justin Novosad wrote:
> The CSS and SVG specifications do not explicitly address the issue of
> gamma-correct blending, but the examples in the CSS spec suggest doing
> things the "wrong" way, which ignores gamma correctness.

The SVG specification explicitly says that filer operations are in
linear-light sRGB by default (with an option to change to sRGB, where
speed is more important than getting the right result); and that all
other operations are (sadly) in gamma-encoded sRGB by default (with an
opt-in for linear-light sRGB).

The CSS Compositing specification, sadly, requires operations in
gamma-encoded sRGB. This choice was primarily driven by backwards
compatibility with existing content; and secondarily with compatibility
of blend modes, as popularized in Adobe Photoshop, which are also
computed in gamma-encoded RGB spaces.

CSS Compositing thus needs to add an opt-in for linear-light compositing.

--
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media