Canvas color spaces: wide-gamut, and high bit-depth rendering


Alright that makes sense.

Though that space (are we talking about scRGB?) works well for alpha compositing, values outside the [0,1] range will cause unexpected behaviors with other type of compositing operations. For example, operations that multiply or divide color components with other color components may behave in unexpected ways.

Anyways… The more important issue here is that there needs to be a guarantee that the color space used for compositing be an adequate intermediate. We discussed this in the Khronos thread and we agreed that the exact color space used for compositing is up to the implementatation but it must satisfy the requirement that using the space as an intermediate between the canvas’s color space and the display’s profile most not cause any undue banding or gamut clamping. I forgot to capture that in the proposal. I’ll fix it.

Thanks for spotting that! Let’s follow what WebGL does.


I’ve meant it’s not supposed to be exposed literally as 10-10-10-2. You’d need copy and convert to 16-16-16(-16) to expose it. I wouldn’t call that optimal, but rather good-enough :wink:


If getImageData is not color-corrected to a profile known by the page, then it cannot be used. The pixel values are technically undefined and unknown, and app can only assume the profile is reasonably close to sRGB (and the more unusual the profile is, the worse color skew it’ll cause).

This would be terrible for photo editing applications that need to use asm.js & getImageData almost exclusively, and have to have high quality color at the same time.

(and if getImageData is left in color space of the display, which is then made known via some other means, then it’s a vector for fingerprinting and cross-browser persistent tracking :frowning: ).


The only case where the exact color space would be unknown is with “legacy-srgb”. Apps that want to do direct pixel manipulation in a known color space would stay away from that.


At the WebGL working group F2F meeting yesterday, it was reiterated that color spaces should be decoupled from the notion of numeric format (bit-depth, fixed-point vs floating-point). Implementations would not be obligated to support all possible formats, but they should however support all color spaces. This still leaves a few questions needing to be resolved:

  • Which numeric formats are supported and which are mandatory?
  • What a about gamma-correction? I would like propose that when the numeric format is a floating-point type, the raw color values should not be gamma-corrected (i.e. linear), and for non-float formats the values would be gamma corrected.


I have re-hashed the proposal based on feedback that was received from this thread and from other sources.


  • Color space and pixel format are now two independent parameters
  • p3 was added as a built-in color space
  • legacy-srgb was removed and folded into srgb
  • Performing liner pixel arithmetic when the encoding is gamma-corrected is now a controllable option

Link: Canvas color space proposal



Are you considering dynamic range as well as color space ? As high dynamic range displays become available, there are two reasons to explicitly consider dynamic range: (1) scene referred images and graphics authored with regular displays in mind will look uncomfortably bright if mapped to the full dynamic range of an HDR display. For laptops / desktops, the authors’ expectation was likely that peak white in their image / graphics appears the same as the “page white” background of an ordinary window (i.e. whatever is comfortable for the user as a window background), far less than the peak brightness of the display. (2) images extracted from HDR video may be display referred (if coded with the PQ transfer function), in which case explicit author intent as to the brightness in a reference environment is available.

This issue is also being discussed in CSS and there is a proposal for a Community Group to further align work across groups on this topic:

… Mark


That is an excellent point. And no, it has not been considered in this proposal. Thanks for bringing that up. We’d most likely adapt this feature to follow the lead of CSS. Do you think there are any special considerations that are required in v1 of the canvas color space feature so that it may be extended to add more HDR considerations in the future?

I think the current proposal is not painting us into a corner with respect to HDR, but perhaps my understanding of the issue is too shallow.

I think we should add this proposal to the scope of that community group.


As it happens, the CG now exists (rather than just being a proposal). You can sign up at:


The proposal has been moved to the WICG github org. Feel free to send issues and pull requests directly in that repo.