Potential bug in okLCH/okHSV conversion?

[intervexual]

Hi! Thanks for providing this library! I think I have encountered a bug in conversion to okHSV. I'm getting saturation & value results that aren't quite right.

from coloraide import Color
from coloraide import Color as Base
from coloraide.spaces.okhsv import Okhsv

cob = Color('oklch', [.32, .04, 214])
to_dict = cob.convert('okhsv').to_dict()
result = to_dict['coords']
print(result)

Which yields: [214.0, 0.581, 0.262]

Expected result: [214.0, 0.41, 0.37] - per https://bottosson.github.io/misc/colorpicker/#305058

Similarly:

cob = Color('oklch', [.12, .7, 280])
to_dict = cob.convert('okhsv').to_dict()
result = to_dict['coords']
print(result)

Yields [280.0, 1.66, 1.372] - values above 100%??

Expected: [280.0, 0.71, 0.21] - see https://bottosson.github.io/misc/colorpicker/#151539

EDIT TO ADD:

Just tried starting from hex sRGB, and that conversion to okHSV works:

cob = Color('#151539')
to_dict = cob.convert('okhsv').to_dict()
result = to_dict['coords']

Yields: [279.22273809286304, 0.7015946823729571, 0.2116489009743403]

And similarly starting with Color('#305058') yields [215.36804652630022, 0.4115791426600469, 0.36756243768541785].

FURTHER EDIT:

I think maybe the issue is okLCH? The luminence is off in the conversion of sRGB to okLCH:

cob = Color('#151539')
to_dict = cob.convert('oklch').to_dict()
result = to_dict['coords']
print(result)

Yields: [0.2198500841232686, 0.06805989426819331, 279.22273809286304]

Expected: [0.12, 0.07, 280]

And for the example of #305058 the okLCH conversion yields
[0.4098533433314402, 0.03987728406731395, 215.36804652630025]

Expected: [0.32, 0.04, 215]. Again the chroma & hue are fine, but luminence is off.

[facelessuser]

@intervexual Are you comparing apples to apples? I think not. Let me explain.

You noted that you can't get results that match Bottosson's color picker when using OkLCh to Okhsv or vice versa. The problem is that you need to pay closer attention, notice that the colorpicker is not showing OkLCh, but OkLrCh. The article explains that to create Okhsv and Okhsl that a toe function was applied to the lightness in a variation of OkLCh.

Note in this example that we can convert fine from sRGB HEX to Okhsv. Note that when we convert from sRGB HEX to OkLCh that the lightness doesn't match. If you read the article on Okhsl and Okhsv, you'll notice that he talks about a new lightness: https://bottosson.github.io/posts/colorpicker/#intermission---a-new-lightness-estimate-for-oklab. This is what is used to create Okhsl and Okhsv. So in the example, when we apply the toe function to the lightness, we now match the results in OkLrCh. So, not a bug, just a misunderstanding of what is being shown in the colorpicker page. Hopefully that answers your question.

[facelessuser]

Note that I've converted this issue to a discussion.

[intervexual]

Thank you for resolving the confusion. The issue is evidently not a bug in your code. I have submitted a pull request to Bottosson's colour widget to improve the wording because at present it misleadingly tells the reader that "Here standard HSV and HSL color pickers are compared with Oklch, Okhsv, Okhsl and Hsluv" which certainly gave me the impression that it was standard okLCH being compared in the tool. Sorry to bother you, and again, thank you for providing this library.

[facelessuser]

You're very welcome. Glad I could resolve the issue.