Re: Pre-meeting Thoughts on HDR Canvas

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<mailto: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.