A few questions on Color

[cdaein]

Hi,

I was working with rgb and srgb on hiccup canvas and had a few questions on color conversion.

1. In the example below, I can see why linear RGB colA can not be accurately displayed, but when I converted colA to colC (sRGB), I was expecting that I would get the same color as colB (sRGB). I must have misunderstood something.

// RGB
const colA = rgb([1.0, 0.2, 0.0]);
// SRGB
const colB = srgb([1.0, 0.2, 0.0]);
// RGB -> SRGB
const colC = srgb(colA);

draw(
  ctx,
  group({}, [
    rect([0, 0], [Math.ceil(width / 3), height], {
      fill: colA,
    }),
    rect([Math.ceil((width / 3) * 1), 0], [Math.ceil(width / 3), height], {
      fill: colB,
    }),
    rect(
      [Math.ceil((width / 3) * 2), 0],
      [Math.ceil((width / 3) * 2), height],
      {
        fill: colC,
      },
    ),
  ]),
);

2. Somewhat related to it, is there a way to use "display-p3" wide gamut color in hiccup canvas? I searched with the keyword but couldn't find any reference to it. I am currently manually setting the canvas attribute and pass the color as string:

rect([0, 0], [Math.ceil(width / 3), height], {
  fill: `color(display-p3 ${colA[0]} ${colA[1]} ${colA[2]})`,
})

Thank you for reading!

[postspectacular]

Hi @cdaein — currently, there's no (not yet) built-in support for P3 in the color and/or hiccup-canvas packages, simply because these libraries predate the general P3 support in browsers... I'm also still wondering how to best solve this and would be grateful for any ideas oreven other references how this could be handled best...

As to your other question, I will get back to you on that later...

[postspectacular]

Hey @cdaein — sorry for the delay (had to get a new release out first), here's an attempt to explain why your 3 colors make sense the way they're dealt with right now:

When you create a color (any type) in the form rgb(a,b,c) or rgb([a, b, c]) then the values given are assumed to be in that intended color space already. For example, if I create hsl(0,1,0.5) (or same for hsl([0,1,0.5])), then the values given are interpreted as H,S,L, as you'd expect.... The only time an automatic conversion happens is if you pass a color of a different type as argument, e.g. as in your colC case, or if you'd pass a CSS string rgb("#abc"). In the latter case, the CSS color would first be parsed as integer, then converted to linear RGB. You can see the difference here:

rgb("#abc")
// $Color [rgb] { buf: [ 0.40197777983219574, 0.4969329950608704, 0.6038273388553378, 1 ], offset: 0, stride: 1 }

srgb("#abc")
// $Color [srgb] { buf: [ 0.6666666666666666, 0.7333333333333333, 0.8, 1 ], offset: 0, stride: 1 }

hsl("#abc")
// $Color [hsl] { buf: [ 0.5833334374998698, 0.24999953125087915, 0.7333333333333334, 1 ], offset: 0, stride: 1 }

Now maybe you can already see why colC doesn't end up the same as colB: You're providing the exact same values to both colA and colB, but when colA is then converted to sRGB, the resulting components are obviously going to end up different values than those of colB:

colA = rgb([1.0, 0.2, 0.0]);
// $Color [rgb] { buf: [ 1, 0.2, 0 ], offset: 0, stride: 1 }

colC = srgb(colA);
// $Color [srgb] { buf: [ 0.9999999999999999, 0.48452920448170694, 0, 1 ], offset: 0, stride: 1 }

The same logic (in reverse) then is used when converting colors to CSS strings: A linear RGB color will first be converted to sRGB and then to CSS, whilst an sRGB color will not have to undergo a gamma correction step:

css(colA);
// '#ff7c00'

css(colB);
// '#ff3300'

css(colC);
// '#ff7c00'

Also, the library attempts to use whatever is the best conversion route for a color type. By default the library assumes CSS Color Level 3, but you can also force L4:

colD = oklch(colA);
// $Color [oklch] { buf: [ 0.72528468699035, 0.1886412384962652, 0.14211743633366036, 1 ], offset: 0, stride: 1 }

// CSS L3 doesn't support oklch color space, so conversion will be to hex
css(colD);
// '#ff7c00'

import { CSS_LEVEL4 } from "@thi.ng/color";

// ...but specifying L4 conversions as option, we get...
css(colD, CSS_LEVEL4);
// 'oklch(72.528% 0.189 51.162)'

Does this help?

[cdaein]

This is very helpful!
And CSS_LEVEL4 is very useful to know.
Thank you very much for your kind and detailed answer!

[postspectacular]

Glad to hear :)

Just for reference, here're some more related links:

• https://docs.thi.ng/umbrella/color/#md:color-creation--conversion
• https://docs.thi.ng/umbrella/color/functions/parseCss.html
• https://docs.thi.ng/umbrella/color/functions/css.html

Here're the conversion routes for CSS:

umbrella/packages/color/src/css/css.ts

Lines 28 to 51 in 324d6b7

	export const CSS_LEVEL3: CSSConversions = {
	abgr32: (x) => intArgb32Css(intAbgr32Argb32(x[0])),
	argb32: (x) => intArgb32Css(x[0]),
	hsl: hslCss,
	hsv: hsvCss,
	lab50: (src) => srgbCss(rgbSrgb(null, labRgb([], src))),
	lab65: (src) => srgbCss(rgbSrgb(null, labRgbD65([], src))),
	lch: (src) => srgbCss(rgbSrgb(null, labRgb(null, lchLab([], src)))),
	rgb: rgbCss,
	srgb: srgbCss,
	};
	/**
	* Extended set of direct CSS conversions for use with CSS Color Module Level 4.
	* Based on {@link CSS_LEVEL3}.
	*/
	export const CSS_LEVEL4: CSSConversions = {
	...CSS_LEVEL3,
	lab50: labCss,
	lab65: (x) => labCss(labLabD65_50([], x)),
	lch: lchCss,
	oklab: oklabCss,
	oklch: oklchCss,
	};

Thinking about this a bit further, I will also add a config function to allow setting the default CSS Level. That way other use(r)s of css() (like hiccup-canvas) can also benefit from this... Expect a new release v.soon! :)

[postspectacular]

Okay, this was pretty straightforward:

2d9e505

Updated example usage:

44c2432

Will do some more testing, then hopefully release tomorrow...

[postspectacular]

@cdaein Just released a new version of thi.ng/color (v5.7.0), which now includes the setDefaultCSSConversions() function, as discussed yesterday...

Still have to think how to best support the new color(mode ...) CSS syntax, but small steps... :)

[cdaein]

Can't wait to try it! Thank you. You're amazing. 🙂