Additionally, in the conversion function, hue is calculated like this: const hue = (Math.atan2(oklab.b, oklab.a) * 180) / Math.PI;, while the implementation source has const hue = Math.atan2(oklab.b, oklab.a) * 180 / Math.PI;. I'm humble enough to state that I'm not sure about the brackets here! Needs verification!
While playing around with the
color-form
, it appears that aRGB
input of255, 0, 0
is not a purered
inOkLCH
(visually).evilmartians' converter returns
oklch(62.8% 0.25768330773615683 29.2338851923426)
.Potential Problem
Our implementation assumes that the value range of
C
is[0..1]
. The value of the conversion function https://github.com/Mischback/colorizer/blob/4d13b7ff3938e55b15fa332086589fd704522a5b/src/script/utility/color-processing.ts#L213is then converted to a percent-based value https://github.com/Mischback/colorizer/blob/4d13b7ff3938e55b15fa332086589fd704522a5b/src/script/colorizer/interface/color-form/input-methods.ts#L564 which is plainly WRONG, as W3C CSS Color Module 4 explicitly states, that the range for the
C
component is0% = 0; 100% = 0.4
.Additionally, in the conversion function,
hue
is calculated like this:const hue = (Math.atan2(oklab.b, oklab.a) * 180) / Math.PI;
, while the implementation source hasconst hue = Math.atan2(oklab.b, oklab.a) * 180 / Math.PI;
. I'm humble enough to state that I'm not sure about the brackets here! Needs verification!Possible Fix
Change
input-methods.ts#L564
to eithertmp = roundToPrecision((colorOklch.c / 0.4) * 100, 2).toString();
to keep the percent-based visualization(Number(this.cBText.value) / 100) * 0.4,
tmp = roundToPrecision(colorOklch.c, 5).toString();
to display a raw value insteadThis should be documented in all OkLCH-related functions!