Re: Pre-meeting Thoughts on HDR Canvas

The spec for EXT_sRGB
<https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_sRGB.txt>
explains the concept succinctly.  The gist of it is that if your working
profile is sRGB, then the correct way to apply the blending operations is
to convert the source and destination color values to linear (by applying
the reciprocal of the sRGB transfer function), apply the blend op, then
convert the result back to sRGB (by applying the transfer function) before
writing it out to the frame buffer.  This ensures that the behavior of
blending ops is consistent across color profiles; it also ensures that
blend ops that are designed to mimic physical phenomena (e.g. transparency,
sub-pixel occlusions, lighting) are actually physically correct. 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.

This is a problem, because the visual behaviours of the blending ops can be
very different based on what working profile is used by the canvas.   This
same problem also applies to color gradient interpolation BTW.

On Wed, Jan 27, 2021 at 11:03 AM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> Justin – I don’t understand what you are mean here.
>
>
>
> Color conversion to the specified working profile/space is performed on
> all elements (today using standard ICC-based profile conversion rules) and
> then the blending is simply a bunch of math as defined originally in SVG
> and then in CSS (all of which is originally derived from the PDF imaging
> model).
>
>
>
> What does linearity and the transfer function have to do with any of that?
>
>
>
> Leonard
>
>
>
> *From: *Justin Novosad <junov@google.com>
> *Date: *Wednesday, January 27, 2021 at 9:52 AM
> *To: *Joe Drago <jdrago@netflix.com>
> *Cc: *"public-colorweb@w3.org" <public-colorweb@w3.org>
> *Subject: *Re: Pre-meeting Thoughts on HDR Canvas
> *Resent-From: *<public-colorweb@w3.org>
> *Resent-Date: *Wednesday, January 27, 2021 at 9:51 AM
>
>
>
>
>
>
>
> On Tue, Jan 26, 2021 at 2:51 PM Joe Drago <jdrago@netflix.com> wrote:
>
> * The canvas' working profile / pixel format
>
>   * Determines luminance gamut / luminance range
>
>   * Determines blending
>
>   * Determines precision (banding)
>
>
>
> I've only been following this discussion sporadically, so I am sorry if
> this comment is redundant.
>
>
>
> Though the canvas working profile determines the color space that is used
> for blending, the profile's* transfer function should not affect blending*
> because most blending op arithmetic has a baked-in assumption of
> linearity.  Historically implementations have been performing linear
> blending ops on gamma encoded color values, which is not great.  Fixing
> this obviously creates a challenge for backwards compatibility of legacy
> (SDR) content, but for HDR we have a blank slate and could take this
> opportunity to do things right.   FWIW OpenGL has the same flaw, and faced
> the same SDR backwards compat issue, which was solved by making the correct
> behaviour "opt-in" with the EXT_sRGB extension. Something similar could
> be considered for canvas.
>
>
>
>
>
>
>
>
>
>