If I paste RGB color, resulting oklch has too much precision and doesn’t fit into textbox

[tonsky]

Steps to reproduce:

1. Paste 0067E2 into RGB

Expected:

• OkLCH has something like oklch(54% 0.20 258)

Actual:

• OkLCH has oklch(54.12% 0.203760003850602 258.38835815691493)

[ai]

We do it for a reason. #0067E2 is on the edge of sRGB gamut and with less precision the color will go to P3 gamut.

For instance, #0167e0 does not change gamut after the rounding the numbers, so we show short numbers for it.

So we check does the precision reduction change the gamut and if to change it, we do not round the numbers.

Here is the code

oklch-picker/stores/current.ts

Lines 189 to 194 in 36cd239

	let originSpace = getSpace(origin)
	let accurate = LCH ? lch(origin) : oklch(origin)
	if (originSpace === Space.sRGB && getSpace(accurate) !== Space.sRGB) {
	let rgbAccurate = toRgb(accurate)
	accurate = LCH ? lch(rgbAccurate) : oklch(rgbAccurate)
	}

Any idea how we can improve the algorithm?

[tonsky]

Yes. Round the numbers. If it goes into P3 territory and display can’t show it, it will be rounded down anyway

[ai]

If it goes into P3 territory and display can’t show it, it will be rounded down anyway

Browser will use P3 > sRGB gamut correction which will change the color a little.

As the result you will have a small color shift after hex > OKLCH convert.

[tonsky]

Is that bad? E.g. if I paste #0067E2 into RGB, the color you show in preview is #0167E2. So there’s already an error happening. I think we all expect that color conversions come with a small amount of errors, at least because of precision

[ai]

Here we will have double shift. The second problem is that browser's P3 > sRGB gamut correction could be different leading to a different shift.

[ai]

Another problem is that it is confuse users. They put obviously sRGB color, but tool tell them that it is P3 color.

We added this feature because people asked us in another issue.

[SomeNameDee]

One idea could be, instead of rounding being all-or-nothing ("if the rounded value is a mismatch then don't round at all"), instead round incrementally.
As in, if the initial rounding fails to match, add an additional decimal place and try again until the rounding matches.
Just not sure how much slower this would be; if it's too dramatic a slowdown it might have to be gated behind a config flag or scrapped entirely.

[ai]

I like the idea. Can you send PR?

[ankiiisharma]

hey @ai , would like to work on this. Let me know if this issue is still open. Thanks.

[ai]

@ankiiisharma yes, we still need help here to implement @SomeNameDee algorithm

[ankiiisharma]

hey @ai, hope you are doing well. just raised a PR #161. Could you please take a look and let me know if you have any suggestions for improvements? Thanks!