The code contains a function that, given the target ΔE, generates two colors in floating-point Oklab representation, separated by that distance. But there is no check whether the two generated colors end up rounding to exactly the same one on 8-bit displays. So, I was asked to find a boundary (while the claim was that there were two distinct colors 0.0013 ΔE apart) between RGB(80, 83, 152) and RGB(80, 83, 152). Obviously unfair.
Another issue is that it discards the color pair if the generated coordinates fall outside 100% sRGB. The problem here is that many low-end laptop displays cover significantly less than 100% sRGB, but come with the correct primaries in the EDID, thus causing browsers to display colors correctly if they can and clip colors if they can't. Colors too close to the sRGB boundary will be clipped in your game - different colors generated, different colors when converted to sRGB, same color on the screen because it is out of the screen gamut. Maybe it makes sense to avoid colors with more than 60% saturation?
I hope you post this again when you do - I was presented with the "0.00080" difference a couple times, and it looks like this is where it becomes actually impossible because of this issue.
Are you using Oklab channels to measure delta-E / difference? If so, Oklab is a hacky way to approximate a real colorspace with just one matrix multiplication, the channels have no meaning and are not related to delta-E. Use real Lab*, it'll take 10 minutes with an LLM.
EDIT: Just read the blog post. I thought HSL was bad for design, Oklab is much worse. It just goes right ahead and reuses color science terms so it sounds it got it all right. (dEOK existing and its "JND" being 0.02 absolutely made my head spin. None of this is recognizable to a color scientist)
>dEOK existing and its "JND" being 0.02 absolutely made my head spin. None of this is recognizable to a color scientist
isnt it just because the lightness scale is 0-1 instead of 0-100? i would like to learn more about this, and your comments are contrary to what i see on, for example, https://www.w3.org/TR/css-color-4/
"In CIE Lab color space, where the range of the Lightness component is 0 to 100, using deltaE2000, one JND is 2. Because the range of Lightness in Oklab and OkLCh is 0 to 1, using deltaEOK, one JND is 100 times smaller."
if youd rather just point in the direction of where to read more, that would be fine too. i assumed (wrongly?) that the CSS color specification would be accurate. or, at least, accurate enough to not make heads spin. (any ideas on why w3 got it so wrong? or why they would use OKlab at all, if it is as utterly awful as you imply?)
> "In CIE Lab color space, where the range of the Lightness component is 0 to 100, using deltaE2000, one JND is 2. Because the range of Lightness in Oklab and OkLCh is 0 to 1, using deltaEOK, one JND is 100 times smaller."
It's very correct - but the implications must not be clear.
In the CIELAB space (read: a scientific space), JND is 2. (3 is color science version, but a minor quibble)
In OKLab space, we'll say it's the same, and then account for normalized lightness.
Oklab's lightness isn't CIELAB's lightness, neither are their dimensions the same, so it's like saying "when we measure in kilometers, a Just Noticable Distance is 2 meters. Miles is scaled differently then normalized, but we'll just say it's 2 yards." (and that's being too kind, in practice, 2m ~= 2 yards, and I don't want to give the impression it's a simple linear scaling difference. The example is meant to communicate they're different dimensions entirely)
> i assumed (wrongly?) that the CSS color specification would be accurate. or, at least, accurate enough to not make heads spin. (any ideas on why w3 got it so wrong? or why they would use OKlab at all, if it is as utterly awful as you imply?)
The thrust of my comment isn't that Oklab is so awful it should be banned, in fact, it's specifically mentioned as better than the incumbent. However, continued reusing of color science terminology, and people assuming that it then applies, is both remniscent of HSL and may worse intellectual poverty for software engineers, even the well-intentioned and studied, as it sounds unobjectionable at its face, but would be batshit insane if applied to synonymous areas of science that affect daily life (ex. distance)
awesome, i appreciate the reply, thanks. most of this is all foreign to me, so i am missing a lot of the knowledge most of the things im finding & reading assume i have. the analogy helps.
The code contains a function that, given the target ΔE, generates two colors in floating-point Oklab representation, separated by that distance. But there is no check whether the two generated colors end up rounding to exactly the same one on 8-bit displays. So, I was asked to find a boundary (while the claim was that there were two distinct colors 0.0013 ΔE apart) between RGB(80, 83, 152) and RGB(80, 83, 152). Obviously unfair.