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 aRGBinput of255, 0, 0is not a pureredinOkLCH(visually).evilmartians' converter returns
oklch(62.8% 0.25768330773615683 29.2338851923426).Potential Problem
Our implementation assumes that the value range of
Cis[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
Ccomponent is0% = 0; 100% = 0.4.Additionally, in the conversion function,
hueis 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#L564to 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!