Add color space support for CanvasRenderingContext2D, ImageData, and ImageBitmap #6562

ccameron-chromium · 2021-04-07T00:07:44Z

Add color space support for CanvasRenderingContext2D, ImageData, and ImageBitmap.

NOTE: This PR is being uploaded for initial feedback, it is not ready for wider review (yet).

At least two implementers are interested (and none opposed):
- Chromium
- Mozilla
Tests are written and can be reviewed and commented upon at:
- https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/wide-gamut-canvas
- More being upstreamed
Implementation bugs are filed:
- Chrome: https://crbug.com/1083693
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1703654
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=225140

(See WHATWG Working Mode: Changes for more details.)

/acknowledgements.html ( diff )
/canvas.html ( diff )
/imagebitmap-and-animations.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )

kenrussell · 2021-04-11T05:32:25Z

Note to reviewers: this work has been developed in https://github.com/WICG/canvas-color-space/blob/main/CanvasColorSpaceProposal.md and discussed at great length in the W3C's ColorWeb CG: https://github.com/w3c/ColorWeb-CG .

The artifacts here are the result of months of iteration and have been carefully considered.

domenic

Did a quick first pass; I've got to run to an appointment but this should help get started!

source

domenic · 2021-04-12T19:47:37Z

source

@@ -65610,40 +65678,36 @@ interface <dfn>OffscreenCanvasRenderingContext2D</dfn> {

  <div w-nodev>

-  <!--en-GB--><h5 id="colour-spaces-and-colour-correction">Color spaces and color correction</h5>
-


A significant amount of normative text here is deleted. Can you help reassure me that it's OK to remove these requirements?

Sure! Some of the text is moved around, too -- I'll just go through the points in the old code with an explanation of where they went.

"The canvas APIs must perform color correction at only two points... when rendering images with their own..."

This is now covered by the paragraph at the bottom, "When drawing content to a 2D context, all inputs must be converted to the context's color space before drawing"

This is a bit more expansive, covering not just images, but all content (videos and CSS color spaces have color spaces too)

"The canvas APIs must perform color correction at only two points... when rendering the actual canvas bitmap to the output device"

This is now covered by the phrase "Color space conversion must be applied to the canvas's backing store when rendering the canvas to the output device."

"The toDataURL() method, when invoked..."

The new behavior is in the "Where output format allows it" paragraph

The new behavior is to always use a color profile, instead of never

"In user agents that support CSS, the color space used by a canvas element must match the color space used for processing any colors for that element in CSS."

I think this was already half-obsolete -- the CSS colors now have a well-defined color space

That space is independent of the canvas's color space, and when and how conversion is applied is now defined

So I just deleted it

"The gamma correction and color space information of images must be handled in such a way ..."

This is now at the top "this color space conversion must be identical to the color space conversion that would be applied to an img element..."

It also falls out of the fact that relative colorimetric rendering intent is path-independent (you can convert from space X to Y to Z to W or just X to W directly, and, ignoring quantization error, you get the same result)

This is also a bit shorter now because I chopped out gamma correction words (gamma is part of the color space, no need to mention is separately)

"Furthermore, the rendering of images that have no color correction information..."

This behavior changed and is covered by the "Images that specify no color profile information" line

This matches what CSS Color Level 4 already says

(Let me know if that clarifies everything!)

This is also a bit shorter now because I chopped out gamma correction words (gamma is part of the color space, no need to mention is separately)

Good. Partly because the transfer curve is part of the color space definition, and also because the term "gamma correction" is a poor one. Nothing is being corrected, or is less correct about linear; instead the term "gamma encoding" is better. Although still suboptimal because many transfer curves are not a simple power law (gamma is the exponent in a power law).

source

annevk

Very exciting to see some incremental progress here!

@whatwg/canvas might want to review this as well.

source

annevk · 2021-04-14T11:06:34Z

source

-  of images that have no color correction information (such as those returned by the <code
-  data-x="dom-canvas-toDataURL">toDataURL()</code> method) must be rendered with no color
-  correction.</p>
+  <p>Where output format allows it, the <code data-x="dom-canvas-toDataURL">toDataURL()</code> method, when


output formats allow*

It seems better to define this as part of the toDataURL() definition though. Action at a distance is best avoided in specifications.

Good point. Added this to the "Serializing bitmaps to a file" section. I also clarified that for formats that do not support embedded color profiles, the bitmap should be converted to sRGB before being serialized (the goal being to have a subsequent drawImage of the result from toDataURL be as close to a no-op as possible).

ccameron-chromium · 2021-04-16T05:12:32Z

Thanks everyone for the comments so far. I think that I've covered all of the issues, and I think we've landed in a good place with respect to the questions that we came in here with.

Let me know if there are any other issues or concerns! (And if I've missed any of the corrections -- I did proofread it again again but ... I have an ECC module when reading text that I wrote).

annevk

I found a couple cases remaining in the color space vs colorSpace category.

annevk · 2021-04-16T13:06:35Z

source

@@ -60500,6 +60518,9 @@ interface <dfn>Path2D</dfn> {

   <li><p><code data-x="concept-canvas-desynchronized">desynchronized</code>, set to this context's
   <span data-x="concept-canvas-desynchronized">desynchronized</span>.</p></li>
+
+   <li><p><code data-x="concept-canvas-color-space">colorSpace</code>, set to this context's


color space

The problem here is the first one (on this line) should be dom-canvasrenderingcontext2dsettings-colorspace

Ah, all bullet points in this section make that mistake! I updated concept-canvas-alpha,desynchronized,color-space to dom-canvasrenderingcontext2dsettings-alpha,desynchronized,colorSpace

annevk · 2021-04-16T13:08:11Z

source

@@ -60500,6 +60518,9 @@ interface <dfn>Path2D</dfn> {

   <li><p><code data-x="concept-canvas-desynchronized">desynchronized</code>, set to this context's
   <span data-x="concept-canvas-desynchronized">desynchronized</span>.</p></li>
+
+   <li><p><code data-x="concept-canvas-color-space">colorSpace</code>, set to this context's
+   <span>output bitmap</span>'s <span data-x="concept-canvas-color-space">color space</span>.</p></li>


It's not associated with the output bitmap though, right? It's part of the context and affects how the output bitmap is rendered. Otherwise you need a different concept- here.

Conceptually there are three distinct things that I may not have been precise about in my language.

canvas element, which doesn't have its own color space

rendering context (2D or WebGL), which has a color space that affects how things are rendered

output bitmap (or backing store), which will be a bitmap where the pixels are in the rendering context's color space

I did a quick sweep of the patch and updated "output bitmap" to be "context" here. Later on, in the "When drawing content to a 2D context..." text, I referred to the "canvas's color space" when the "context's color space" would have been more precise.

annevk · 2021-04-16T13:10:46Z

source

-  values must not be <span data-x="concept-premultiplied-alpha">premultiplied by alpha</span>.</p>
+  values must not be <span data-x="concept-premultiplied-alpha">premultiplied by alpha</span>.
+  Pixel values must be converted from the <span>output bitmap</span>'s
+  <span data-x="dom-CanvasRenderingContext2DSettings-colorSpace">color space</span> to the returned


This looks wrong as well.

Gah! Sorry missing it! This time did the s/dom-CanvasRenderingContext2DSettings-colorSpace/concept-canvas-color-space/ for real.

(Note that I didn't remove the "output bitmap" part, because "bitmap" seems most correct in this situation, although equivalent to the "context").

annevk · 2021-04-16T13:12:03Z

source

+  values must not be <span data-x="concept-premultiplied-alpha">premultiplied by alpha</span>.
+  Pixel values must be converted from the <span>output bitmap</span>'s
+  <span data-x="dom-CanvasRenderingContext2DSettings-colorSpace">color space</span> to the returned
+  <code>ImageData</code> object's <span data-x="dom-imagedata-colorSpace">color space</span> using


This too. This is referencing an IDL attribute and those should use <code> (and camelcase).

Changed the first one to s/settings-colorSpace/concept-color-space/, changed the second on to s/span/code/

annevk · 2021-04-16T13:13:59Z

source

-  match the color space used for processing any colors for that element in CSS.</p>
+  <p class="note">The <a href="https://drafts.csswg.org/css-color/#untagged">Color Spaces of Untagged Colors</a>
+  section of <cite>CSS Color</cite> specifies that images that specify no color profile information are assumed
+  to be in the sRGB color space.<ref spec=CSSCOLOR></p>


Maybe merge this note into the note below?

Makes sense -- merged them into a single note.

domenic

Looking great; my review, like @annevk's, is down to some nits at this point.

domenic · 2021-04-16T17:39:07Z

source

@@ -60500,6 +60518,9 @@ interface <dfn>Path2D</dfn> {

   <li><p><code data-x="concept-canvas-desynchronized">desynchronized</code>, set to this context's
   <span data-x="concept-canvas-desynchronized">desynchronized</span>.</p></li>
+
+   <li><p><code data-x="concept-canvas-color-space">colorSpace</code>, set to this context's


The problem here is the first one (on this line) should be dom-canvasrenderingcontext2dsettings-colorspace

domenic · 2021-04-16T17:44:22Z

source

+  <p>Color space conversion must be applied to the canvas's backing store when rendering the canvas to the
+  output device. This color space conversion must be identical to the color space conversion that would
+  be applied to an <code>img</code> element with a color profile that specifies the same color space as
+  the canvas's backing store.</p>


"the same color space as the canvas's concept-canvas-color-space", maybe? (Hyperlinked)

Added the link, but left it reading the same color space as the canvas's backing store. Because we're talking about the pixels in the buffer, I think that talking about the color space of the backing store is the right scope (even though the "backing store" space and "context" space are the same).

domenic · 2021-04-16T17:45:28Z

source

-  of images that have no color correction information (such as those returned by the <code
-  data-x="dom-canvas-toDataURL">toDataURL()</code> method) must be rendered with no color
-  correction.</p>
+  <p>When drawing content to a 2D context, all inputs must be converted to the context's color space


"the canvas's concept-canvas-color-space" here and below?

Changed to ``converted to the context's color space``` in the three references.

domenic · 2021-04-16T17:46:34Z

source

+  <p class="note">The color space for CSS colors is defined in <cite>CSS Color</cite>: <ref
+  spec=CSSCOLOR>. There do not exist any inputs to a 2D context for which the color space is undefined.</p>


Suggested change

The color space for CSS colors is defined in <cite>CSS Color</cite>: <ref

spec=CSSCOLOR>. There do not exist any inputs to a 2D context for which the color space is undefined.

The color space for CSS colors is defined in <cite>CSS Color</cite>. There do not

exist any inputs to a 2D context for which the color space is undefined. <ref spec=CSSCOLOR>

(stylistic nit)

Chnaged to a terminal <ref spec=CSSCOLOR> in the merged comment.

domenic · 2021-04-16T17:47:50Z

source

+  Pixel values must be converted from the <span>output bitmap</span>'s
+  <span data-x="dom-CanvasRenderingContext2DSettings-colorSpace">color space</span> to the returned
+  <code>ImageData</code> object's <span data-x="dom-imagedata-colorSpace">color space</span> using
+  relative colorimetric intent.


Can "relative colorimetric intent" hyperlink anywhere? (Fine if not, but it would be a nice bonus if it could.)

How about https://drafts.csswg.org/css-color-4/#valdef-color-profile-rendering-intent-relative-colorimetric in CSS Color 4

Added the link to the places where it was referenced.

source

annevk · 2021-04-19T09:45:33Z

source

+   "<code data-x="dom-PredefinedColorSpace-srgb">srgb</code>".</p>
+
+   <p>Initialize the <dfn attribute for="ImageData"><code data-x="dom-imagedata-colorSpace">colorSpace</code></dfn>
+   attribute of <var>imageData</var> to <var>cs</var>.</p></li>


This is missing an <li>, but this and the previous step can be simplified as the dictionary is always passed from the perspective of this algorithm (due to IDL) so you don't have to specify the defaulting here again. You can just say 'Initialize ... to settings["colorSpace"].'

Fixed the <li> part.

Holding off on the rest of the change because of the below question about optional-izing the colorSpace key.

source

ccameron-chromium · 2021-04-19T21:30:23Z

I've made the ImageDataSettings object to "create an imagedata object" not be optional, and I think it clears things up quite a bit. I also broke getImageData into separate steps in the text, since its paragraph was getting too long.

Still interested in your opinions about the "default to sRGB" behavior. The change to the text would be to make getImageData set the colorSpace member of its ImageDataSettings argument (but only if it isn't set already).

It has been colorspace in this document since the very beginning (7 November 2016), but on 9 May 2016 we changed colorspace to color space in the HTML Standard quite deliberately: whatwg/html@c92fee2. Recently this was discussed further in whatwg/html#6562 and we decided to stick with color space.

source

annevk

I found some more issues, some might be substantive. (I wish I had gotten further with #3424 as a lot of this would be helped with having more modern foundations.)

annevk · 2021-04-21T12:39:32Z

source

-  <code>ImageData</code> object</span>, with parameter <var>pixelsPerRow</var> set to the
-  absolute magnitude of <var>sw</var>, and parameter <var>rows</var> set to the absolute magnitude
-  of <var>sh</var>. Initialize the image data of the new <code>ImageData</code> object to
+  invoked with two numeric arguments <var>sw</var> and <var>sh</var> and an <code>ImageDataSettings</code>


Suggested change

invoked with two numeric arguments <var>sw</var> and <var>sh</var> and an <code>ImageDataSettings</code>

invoked with two numeric arguments <var>sw</var> and <var>sh</var>, and an <code>ImageDataSettings</code>

source

annevk · 2021-04-21T12:42:13Z

source

@@ -64002,24 +64043,24 @@ try {

  <dl class="domintro">
   <dt><var>imagedata</var> = new <code subdfn data-x="dom-imagedata">ImageData</code>(<var>sw</var>, <var>sh</var>)</dt>


This also changed. It probably needs to get its own (web developer facing) description separately from createImageData() now they behave somewhat differently when it comes to color space.

Good point -- I separated them out. I also moved the two createImageData functions next to each other (they were shuffled because of the shared definitions).

source

annevk · 2021-04-21T12:49:56Z

source

+   <var>imageData</var> to the <dfn dict-member for="ImageDataSettings"><code data-x="dom-ImageDataSettings-colorSpace">colorSpace</code></dfn>
+   member of <var>settings</var>.</p>
+
+   <p>Otherwise, if <var>defaultColorSpace</var> is specified, then initialize the


This should be a new <li> as well. Same below.

annevk · 2021-04-21T12:58:15Z

source

@@ -95092,6 +95177,7 @@ dictionary <dfn>ImageBitmapOptions</dfn> {
  <span>ImageOrientation</span> <span data-x="dom-ImageBitmapOptions-imageOrientation">imageOrientation</span> = "<span data-x="dom-ImageOrientation-none">none</span>";
  <span>PremultiplyAlpha</span> <span data-x="dom-ImageBitmapOptions-premultiplyAlpha">premultiplyAlpha</span> = "<span data-x="dom-PremultiplyAlpha-default">default</span>";
  <span>ColorSpaceConversion</span> <span data-x="dom-ImageBitmapOptions-colorSpaceConversion">colorSpaceConversion</span> = "<span data-x="dom-ColorSpaceConversion-default">default</span>";
+  <span>PredefinedColorSpace</span> <span data-x="dom-ImageBitmapOptions-colorSpace">colorSpace</span> = "<span data-x="dom-PredefinedColorSpace-srgb">srgb</span>";


While reading through the new createImageBitmap() text I started to wonder if these options should also apply to <canvas> and ImageData now that they have color space information that can differ from the desired color space. (If nobody wants to implement that I think at the very least we should throw.)

We also don't seem to consider color space for video and the SVG image element. The latter is probably an oversight?

Also, should concept-imagebitmap-bitmap-data be updated to also have a color space, apart from a width and height?

I think it's probably best for me to take the createImageBitmap part out of this PR, and then take up the issue along with (or on top of) the changes you were suggesting for createImageBitmap.

The original version of the patch had a much shorter section on createImageBitmap and left things more vague and implementation-defined. I've reverted back to an even smaller version of that (not adding the colorSpace field, and just a few wording here and there).

It was for WebGL and WebGPU textures that we added the colorSpace field, but the same behavior can be accomplished in other ways, and it seems better to leave it out.

While reading through the new createImageBitmap() text I started to wonder if these options should also apply to <canvas> and ImageData now that they have color space information that can differ from the desired color space. (If nobody wants to implement that I think at the very least we should throw.)

It depends on how the ImageBitmap is going to be used.

If the goal is to use the ImageBitmap for a WebGL or WebGPU texture, then all content should be converted to a very well-defined pixel format and color space. Because WebGL and WebGPU aren't color managed, the application needs to know its exact starting place, to do the right math for their manual color management. For this use case, createImageBitmap should arguably allow specifying a pixel format, too (RGBA v BGRA v R10G10B10A2 v half-float, etc).

If the goal is to use the ImageBitmap in a 2D or ImageBitmap RenderingContext, then the exact internal representation doesn't matter, and no content should have its pixel format or color space altered. The 2D and ImageBitmap contexts do color management and pixel format conversion internally. Ideally, from a performance perspective, the content shouldn't be converted at all, and createImageBitmap would create some sort of copy-on-write alias of the original source content.

Also, should concept-imagebitmap-bitmap-data be updated to also have a color space, apart from a width and height?

I don't think so. In the case where we're not sending the data into WebGL or WebGPU, we want ImageBitmaps to be in whatever internal color space is most appropriate for them (which for many elements may even be some YUV video format). Any color space we would expose would likely be a lie in some circumstances.

It would be great if we could press ahead and try to get the colorSpace dictionary member specified here instead of pushing it off. ImageBitmap is the path recommended to web developers nowadays for uploading images into WebGL and WebGPU, since it performs all conversions early on, and avoids synchronous re-conversions at the time of use. ImageBitmap behaves distinctly from <canvas> and ImageData in this regard. WebGL, for example, will perform certain operations like vertical flips for most image sources, but by design, does not do these for ImageBitmaps.

Given that ImageBitmap is already being torn between two separate uses (WebGL/GPU vs 2D/ImageBitmap), I don't think it's appropriate to add features to it in this PR. It needs careful separate consideration, and a clear vision of its future.

@kenrussell ImageBitmap is recommended in Chrome, but not in Firefox. Usually you're better off without ImageBitmap intermediaries in Firefox.

I would strongly prefer to cover ImageBitmap/WebGL issues in a separate PR.

There is separate work in Khronos for WebGL (which I believe jdashg volunteered for), and I feel that this will significantly expand the scope of the patch (which is narrowly focused on 2D/ImageData). The class of under-defined behavior that you mentioned already exists and is very wide (importing video to WebGL is the most prevalent example), and I think it needs its own focused treatment, rather than to be being picked up incidentally.

Oh, since it wasn't clear, I'm volunteering to start on that cleanup starting immediately, I just would prefer it to be separated out from this PR. I can also incorporate #3424 into that work if you'd like.

My worry is that we end up in an inconsistent state, which is generally something we try to avoid. I'll defer to @domenic as to whether that's blocking here.

Thanks! I think we'll be able to resolve the issue on the WebGL side of things (and if that goes as I hope, we'll be able to just tighten up some language on this side).

I took a look and I'm comfortable with how this only touches one part of the problem for now, cleanly leaving the rest of future work. I trust @ccameron-chromium to continue with that work.

I'm not really able to evaluate the extent of the problem, but I found

The class of under-defined behavior that you mentioned already exists and is very wide (importing video to WebGL is the most prevalent example), and I think it needs its own focused treatment, rather than to be being picked up incidentally.

compelling to the extent that it's true, and if we can solve it all at once that'd be lovely.

domenic · 2021-04-22T19:57:00Z

I'm working on an editorial update to modernize some stuff while I'm in the area, but it looks good so far. I'll push soon.

However I noticed one potential bigger problem. OffscreenCanvasRenderingContext2D also mixes in CanvasImageData, but does not have a color space member, so the definition of createImageData() doesn't work.

ccameron-chromium · 2021-04-22T21:34:24Z

However I noticed one potential bigger problem. OffscreenCanvasRenderingContext2D also mixes in CanvasImageData, but does not have a color space member, so the definition of createImageData() doesn't work.

I had thought that it mixed in the settings parsing and the color space member, but you're right, it doesn't! I've added these to OffscreenCanvasRenderingContext2D now.

I noticed that OffscreenCanvasRenderingContext2D has a similar alpha property which can be set via CanvasRenderingContext2DSettings. What's odd is that the spec refers to being able to dynamically change it, but there's no API for that (and the setting isn't even accessible -- it's not an attribute, and there is no getContextAttributes mixed in). Is that a known issue?

domenic · 2021-04-22T21:50:50Z

I noticed that OffscreenCanvasRenderingContext2D has a similar alpha property which can be set via CanvasRenderingContext2DSettings. What's odd is that the spec refers to being able to dynamically change it, but there's no API for that (and the setting isn't even accessible -- it's not an attribute, and there is no getContextAttributes mixed in). Is that a known issue?

This is probably worth tracking separately... I agree as written it's odd. I think it's trying to say "Set it to true by default. The 'offscreen 2D context creation algorithm' might change this."

domenic

I'm happy with this PR.

I pushed another commit which does a pretty large editorial modernization of the touched sections as they were starting to get really crufty and I was sad. That sort of thing shouldn't be on contributors but while we're in the area I like to leave things better than they started.

Can you make sure to file a WebKit bug and update the OP with it? Also can we get a commitment to test all the things that changed during review, e.g. handling of invalid values, getImageData-then-putImageData, ... any others I missed?

@annevk are you happy with this landing after those steps?

annevk

I found a couple nits that I can address before landing. I agree with @domenic on the other remaining TODOs here.

One thing I would really appreciate (and maybe we should add this to the specification as well) is a concrete example. E.g., if you create a context using 'display-p3' and then use fillStyle = hexNotation (as per https://drafts.csswg.org/css-color/#hex-notation). Presumably if you then do getImageData() (and don't do color space conversion; but I guess also if you do) you would see some different values there in the data. I think that would be helpful to demonstrate.

source

annevk · 2021-04-27T09:50:30Z

source

-    the actual <code data-x="idl-Uint8ClampedArray">Uint8ClampedArray</code> object passed as the
-    first argument to the constructor.</p>
+    <p class="note">This step does not set <span>this</span>'s data to a copy of <var>data</var>.
+    It's sets it to the actual <code data-x="idl-Uint8ClampedArray">Uint8ClampedArray</code> object


I think an intervening change fixed this (I don't see the typo here anymore)

source

ccameron-chromium · 2021-04-28T06:11:53Z

One thing I would really appreciate (and maybe we should add this to the specification as well) is a concrete example.

I've added an example into the ImageData set of examples in the spec, drawing #FF0000 to a canvas and reading back (234, 51, 35) from getImageData.

annevk · 2021-04-28T06:14:28Z

Thanks Christopher! Would you like to list your name in the Acknowledgments section? I will give this a final look later and get it landed.

ccameron-chromium · 2021-04-28T06:15:04Z

Can you make sure to file a WebKit bug and update the OP with it?

Yes, updated with the WebKit bug.

Also can we get a commitment to test all the things that changed during review, e.g. handling of invalid values, getImageData-then-putImageData, ... any others I missed?

Yes. We are currently working on adding tests for the behaviors that we have updated during iteration here (the things you mention -- handling of invalid values, and also the default behavior for getImageData and createImageData, once we get them working).

That said, several of the tests have already rolled into upstream (getImageData, toBlob, and putImageData, but all with explicit arguments).

ccameron-chromium · 2021-04-28T06:16:15Z

Thanks Christopher! Would you like to list your name in the Acknowledgments section? I will give this a final look later and get it landed.

Thank you! Yes, certainly, add my name.

annevk · 2021-04-28T09:39:49Z

@ccameron-chromium it seems that @domenic's editorial commit got lost when you rebased. I'll try to revive what I can from https://github.com/whatwg/html/compare/eb6c996d7461ac4175b5a47ef381f0fcaa9845ac..93fea05ccf4222977becb51530e85810c24ce218.

annevk · 2021-04-28T10:37:44Z

I think all is in order now, but given the mishap I'd like to wait for @domenic to return so he can do a final check and land this Monday.

And once it's landed we can do a small follow-up PR to remove the remaining sRGB references.

Define its behavior both for presenting the rendering context's results, and uploading textures via texImage2D / texSubImage2D from DOM inputs (the TexImageSource union type). Follows whatwg/html#6562 , in which the PredefinedColorSpace enum was defined, and its behavior for 2D canvas contexts specified.

…ringContextBase. (#3292) Define their behavior both for presenting the rendering context's results, and uploading textures via texImage2D / texSubImage2D from DOM inputs (the TexImageSource union type). Notably: - The drawing buffer is reallocated when drawingBufferColorSpace is changed. - unpackColorSpace applies to ImageBitmaps. Follows whatwg/html#6562 , in which the PredefinedColorSpace enum was defined, and its behavior for 2D canvas contexts specified. Address review feedback from kainino, ccameron-chromium and kdashg.

ccameron-chromium marked this pull request as draft April 9, 2021 21:33

ccameron-chromium force-pushed the canvas_color branch 2 times, most recently from 0ea9c96 to 6ca499d Compare April 10, 2021 04:00

ccameron-chromium marked this pull request as ready for review April 10, 2021 04:05

domenic reviewed Apr 12, 2021

View reviewed changes

ccameron-chromium force-pushed the canvas_color branch from 6ca499d to 84e7ffc Compare April 13, 2021 06:15

annevk mentioned this pull request Apr 13, 2021

createImageBitmap(videoFrame) Semantics w3c/webcodecs#159

Closed

annevk reviewed Apr 14, 2021

View reviewed changes

annevk reviewed Apr 16, 2021

View reviewed changes

tabatkins mentioned this pull request Apr 16, 2021

[css-color-4][css-color-5] Consistently spell as "color space" w3c/csswg-drafts#6217

Closed

domenic reviewed Apr 16, 2021

View reviewed changes

tabatkins mentioned this pull request Apr 16, 2021

Add "color space" to Commonly Misspelled Terms w3c/manual-of-style#16

Closed

ccameron-chromium force-pushed the canvas_color branch from 2ff1790 to 3005648 Compare April 18, 2021 05:52

annevk reviewed Apr 19, 2021

View reviewed changes

annevk mentioned this pull request Apr 20, 2021

Add space to color space whatwg/whatwg.org#359

Merged

kdashg approved these changes Apr 20, 2021

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

annevk reviewed Apr 21, 2021

View reviewed changes

domenic approved these changes Apr 22, 2021

View reviewed changes

annevk mentioned this pull request Apr 27, 2021

CSSColorValue as input for CanvasRenderingContext2D fill and stroke styles #6609

Closed

3 tasks

annevk reviewed Apr 27, 2021

View reviewed changes

ccameron-chromium added 2 commits April 27, 2021 18:06

Add color space support for 2D Canvas, ImageData, and ImageBitmap

bd5bf34

Incorporate domenic feedback part 1

a3050a9

ccameron-chromium added 5 commits April 27, 2021 18:06

Simplify ImageBitmap

cb4405e

Separate new ImageData from createImageData

f18a0a6

Add steps for OffscreenCanvas

816289b

Change sRGB refs to srgb in css-color

162c788

Clean up 100 col lines

93fea05

ccameron-chromium force-pushed the canvas_color branch from eb6c996 to 93fea05 Compare April 28, 2021 05:25

Add example

58699f2

annevk added 3 commits April 28, 2021 12:04

Formatting

a5bd3e2

Restore Domenic's refactor

6180f9a

oops

ef93fdc

annevk mentioned this pull request Apr 28, 2021

Adds wide-gamut support #3882

Closed

Final nits and cleanups-while-in-the-area

5e497f3

domenic added addition/proposal New features or enhancements topic: canvas labels May 3, 2021

domenic merged commit 85cb202 into whatwg:main May 3, 2021

domenic mentioned this pull request May 7, 2021

WebGL access to decoded planes w3c/webcodecs#37

Open

kenrussell mentioned this pull request May 18, 2021

Add colorSpace attribute to WebGLRenderingContextBase KhronosGroup/WebGL#3285

Open

ccameron-chromium mentioned this pull request Jun 10, 2021

Canvas 2D color management w3ctag/design-reviews#646

Closed

1 task

kenrussell mentioned this pull request Jun 15, 2021

Add drawingBufferColorSpace/unpackColorSpace attributes to WebGLRenderingContextBase. KhronosGroup/WebGL#3292

Merged

annevk mentioned this pull request Oct 20, 2021

"Paint the region of the image" in what colorspace? #7245

Open

annevk mentioned this pull request Feb 20, 2023

Canvas 2D context color serialization #8917

Closed

adroitwhiz mentioned this pull request Apr 4, 2024

ImageDataSettings should probably be called ImageDataOptions #10248

Closed

		@@ -65610,40 +65678,36 @@ interface <dfn>OffscreenCanvasRenderingContext2D</dfn> {

		<div w-nodev>

		<!--en-GB--><h5 id="colour-spaces-and-colour-correction">Color spaces and color correction</h5>

		<p class="note">The color space for CSS colors is defined in <cite>CSS Color</cite>: <ref
		spec=CSSCOLOR>. There do not exist any inputs to a 2D context for which the color space is undefined.</p>

	invoked with two numeric arguments <var>sw</var> and <var>sh</var> and an <code>ImageDataSettings</code>
	invoked with two numeric arguments <var>sw</var> and <var>sh</var>, and an <code>ImageDataSettings</code>

		@@ -64002,24 +64043,24 @@ try {

		<dl class="domintro">
		<dt><var>imagedata</var> = new <code subdfn data-x="dom-imagedata">ImageData</code>(<var>sw</var>, <var>sh</var>)</dt>

Add color space support for CanvasRenderingContext2D, ImageData, and ImageBitmap #6562

Add color space support for CanvasRenderingContext2D, ImageData, and ImageBitmap #6562

Conversation

ccameron-chromium commented Apr 7, 2021 • edited by pr-preview bot Loading

kenrussell commented Apr 11, 2021

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ccameron-chromium commented Apr 16, 2021

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ccameron-chromium commented Apr 19, 2021

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Apr 22, 2021

ccameron-chromium commented Apr 22, 2021

domenic commented Apr 22, 2021

domenic left a comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ccameron-chromium commented Apr 28, 2021

annevk commented Apr 28, 2021

ccameron-chromium commented Apr 28, 2021

ccameron-chromium commented Apr 28, 2021

annevk commented Apr 28, 2021

annevk commented Apr 28, 2021

ccameron-chromium commented Apr 7, 2021 •

edited by pr-preview bot

Loading