Support the p3 color space in the raster mark

[jwoLondon]

Enhancement request: Allow the raster mark to use CSS4 colour specifications and the P3 colour space.

Marks that generate SVG currently work with modern colour specifications, meaning they can specify colours using new colour spaces such as Oklch. For example, this works correctly:

Plot.cellX([1], { fill: "oklch(52.6% 0.24 29.5deg)" }).plot()

Not only does this give access to improved perceptual colour spaces, but also allows deeply saturated colours outside the sRGB gamut but in the P3 gamut to be rendered correctly on displays that support P3 (with a graceful fallback to the nearest sRGB colour for those which don't).

However, the raster mark, which relies on Canvas, does not currently support either modern colour specification, nor the P3 colour space. The following renders a raster as black rather than the intended saturated red:

Plot.raster([1], {
  width: 1,
  height: 1,
  fill: "oklch(52.6% 0.24 29.5deg)"
}).plot()

It would be great to have support for modern colour specs in Canvas.

As far as I can see, the current implementation creates an sRGB canvas rather than a p3-friendly one. I think that would just require

getContext("2d", { colorSpace: "display-p3" });

But handling CSS 4 colour specs looks a little more tricky as the implementation seems to rely on d3.color which currently does not handle the modern comma-free colour format. I note d3 issue #87 though.

[Fil]

I would love that, also for "p3" color scales.

[Fil]

Another potential problem (if I remember correctly from my last tentative), is that the canvas we create is then serialized into the SVG with https://github.com/observablehq/plot/blob/1d01e254282a9cc3b8352f0b362ae3e2d35ad6f0/src/marks/raster.js#L168 I'm not sure if we can keep its colorSpace as we do that.

[Fil]

To close the loop, this fantastic notebook just published on the topic:

• https://observablehq.com/@jwolondon/hello-modern-colour-spaces
• https://talk.observablehq.com/t/hello-modern-colour-spaces/9673

(thanks, @jwoLondon!)

[mbostock]

We don’t use d3-color for parsing anymore, as of #1454 (#1851). See isColor:

https://github.com/observablehq/plot/blob/e50254d0340181cc1b8cca749da96a1e10abfc94/src/options.js#L514-L527

So I think the only thing missing here is some way of specifying the colorSpace for the raster mark’s canvas. Retitling the issue accordingly.

[Fil]

The raster mark uses d3.rgb: https://github.com/observablehq/plot/blob/e50254d0340181cc1b8cca749da96a1e10abfc94/src/marks/raster.js#L135 https://github.com/observablehq/plot/blob/e50254d0340181cc1b8cca749da96a1e10abfc94/src/marks/raster.js#L145

I've added lots of comments on #2143 which I should probably transfer here at some point.

[mbostock]

Ah thanks for reminding me @Fil. I like your proposed solution. How does it perform going through canvas?

[Fil]

It sure takes a hit: on my machine rasterVaporP3 takes about 300ms, compared to rasterVapor 110ms.

Still, it's not too awful, and it becomes an optimization problem. It will be fun to research once we think it's "correct".

I feel it would be useful to apply this technique also in the srgb + CSS4 case — unless we get to a point where using fillRect is faster than editing the data matrix directly… but I doubt that there is any chance of that happening). Then we can say that css 4 colors are fully supported.

[Fil]

Another interesting post on the topic, by @clhenrick: https://clhenrick.io/blog/color-experiments-with-oklch/