Clamp chroma to displayable RGB gamut?

[mbostock]

In R, fixup defaults to TRUE. We need some equivalent to this (but faster, hopefully, at least using binary search):

function fixup(c) {
  while (!c.displayable()) --c.c;
  return c;
}

This makes a pretty big difference if you want to, say, emulate ggplot2’s hue color scale.

[danburzo]

I can give binary search a shot. Can you let me know the top-level API you have in mind for this?

(For visual reference, here's a video of how the sRGB gamut looks in LCh, in Lab, and in XYZ)

Also, it seems that in R fixup just clamps the R, G, B values to the [0-255] interval, if I'm looking in the right place, but I'll be curious to see if finding the largest Chroma that's displayable gives substantially different RGB values than plain clamping.

[mbostock]

Hmm, we already clamp to [0, 255] when formatting RGB as a string:

d3-color/src/color.js

Lines 241 to 248 in 8c37e32

	toString: function() {
	var a = this.opacity; a = isNaN(a) ? 1 : Math.max(0, Math.min(1, a));
	return (a === 1 ? "rgb(" : "rgba(")
	+ Math.max(0, Math.min(255, Math.round(this.r) || 0)) + ", "
	+ Math.max(0, Math.min(255, Math.round(this.g) || 0)) + ", "
	+ Math.max(0, Math.min(255, Math.round(this.b) || 0))
	+ (a === 1 ? ")" : ", " + a + ")");
	}

So, maybe we don’t need this after all?

[danburzo]

I wrote an Observable notebook to explore the difference between RGB clamping and Chroma clamping: https://beta.observablehq.com/@danburzo/hcl-chroma-clamping-vs-rgb-clamping

Chroma clamping looks like the 'correct' solution to me, because it does not alter the hue of the resulting color when you increase the chroma past the RGB gamut. (This happens because the RGB doesn't care how far off the R, G, and B components are out of bounds). It also maps L = 0 to pure black and L = 100 to pure white.

(Tangential question: can we somehow proportionally adjust the R, G, B components to get the same result as chroma clamping, but much faster?)

P.S. Apparently L = 100 does not result in a displayable color regardless of the chroma, so taking the L slider to the max will currently result in an infinite loop :P

[curran]

@danburzo I can't see the notebook. Did you hit "publish"?

Thanks for this cool work!

[danburzo]

@curran, oops :) Missed that, thanks! Updated the link in the original comment. (Mind some experiments I'm currently doing with proportional R,G,B clamping)

[danburzo]

I've updated the notebook to reflect the chroma clamping through the bisection method in comparison with the linear method. It converges to a solution in 13–14 iterations for Δ = 0.01, so I think it should be pretty fast.

[mbostock]

Nice! Chroma clamping is definitely noticeable when L is high.

I bet there is a closed form to do the clamping… but I’m not sure I’ll be able to figure it out. Another possibility is that we do simple RGB clamping when L is low, since the chroma difference there is negligible.

[danburzo]

Also added some color ramps to the notebook, and hue-chroma discs in a fork.

[danburzo]

Looking at the ramps and discs in the notebook, it's not readily apparent that chroma clamping is substantially better than RGB clamping for some use-cases... It does have a few useful properties, such as being able to obtain blacks and whites by adjusting the Lightness of the color, and the fact that it maintains the Hue. Maybe it's something to be implemented as a separate method, if at all.

[mbostock]

A cubehelix disk, for fun:

disc((r,t) => d3.cubehelix(t, 1, Math.sqrt(1 - r / 256)))