raster colorSpace

[mbostock]

Fixes #2138. Probably needs a test… I didn’t actually verify that it works.

[Fil]

Tested with success. This shows that it can work — technically speaking the serialization of the canvas does not suppress the color-space attribute. Using colorSpace: "display-p3" with no further change allows to make the image more vibrant. However, on its own this is incorrect for data visualization.

For example, if a color scale maps a value x to the "red" color, it is displayed as "red" or "#ff0000" in a dot mark or in a legend. In a traditional (sRGB) raster mark, it is rendered as the (#ff, #00, #00) byte triplet. However, when the raster is using the display-p3 color space, the same color must be represented by its xyz coordinates (#ea, #33, #23), not by its srgb values. If we don't do apply any conversion, it results in a different color (which we could name "vivid red").

In other words, when using display-p3, we have to "tone down" the byte values of colors that belong to the sRGB gamut, with an sRGB→P3 mapping [1]. This is necessary to ensure that colors are "true" and consistent, at least on p3 capable displays.

(As an aside, the developer might need to set colorSpace only if they detect that the display is capable of representing those colors — on my setup it depends if I'm using the laptop screen or the external monitor, which further complicates the matter. But I think this is out of scope for this PR, and belongs to documentation.)

In a second step, we'll want to enable more colors — such as our "vivid red" — to be encoded too. But we need a way to specify them statically (like color(display-p3 1 0 0)) and in color interpolators. I think this means we need to create d3.xyz, d3.oklch as the equivalent of d3.rgb and d3.hcl, add CSS4 parsing to d3.color, and maybe also create a "xyz" color interpolator (d3.interpolateXyz, equivalent of d3.interpolateHsl). EDIT: See #2145 instead! much simpler.

In a later stage, we'll want to provide "p3-enabled" or "vivid" color schemes (continuous, ordinal, etc.). A cheap way of doing this might be to add an option such as color: {theme: "oranges", vivid: true} to "boost" the scheme by mapping r,g,b directly to p3. (We might also want to create new schemes, but that's more work.)

[1] references https://www.russellcottrell.com/photo/matrixCalculator.htm and https://observablehq.com/@jrus/srgb
PS: it's not clear to me if/how we should apply the gamma correction in this context.

[jwoLondon]

Helpful comments @Fil

On a possible color: {theme: "oranges", vivid: true}, and more generally with non-sRGB colour spaces, it is probably worth keeping the door open for BT.2020 ('Rec2020") and other future enhanced colour spaces. There would be some ambiguity for vivid:true: Would that mean highest spec colour space or P3 or some other rule?