- From: Justin Novosad <junov@google.com>
- Date: Wed, 27 Jan 2021 09:51:32 -0500
- To: Joe Drago <jdrago@netflix.com>
- Cc: public-colorweb@w3.org
Received on Wednesday, 27 January 2021 14:51:56 UTC
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. > > > > >
Received on Wednesday, 27 January 2021 14:51:56 UTC