Request: Add oklch output format

[rmunn]

Background

Now that oklch is available in most browsers, it would be nice to be able to have oklch as an output format option for hyprpicker.

In case you're not familiar with oklch and oklab, they are color definition methods recently added to CSS whose intent is better perceptual fidelity; i.e., when you change the lightness of blue, it should stay blue and not look purplish. The existing lch function doesn't actually match how the human eye perceives color very well, which is why it ends up changing the color of a blue-white gradiant. See https://atmos.style/blog/lch-vs-oklch for a good illustration (the "Hue in LCH vs OKLCH" section is about halfway down the page).

Desired result

What I'd like is an output format that prints the following: oklch(59.246% 33.42% 180) or, if there's an alpha component, oklch(59.246% 33.42% 180 / 0.5). I.e., the same format as accepted in CSS. The lightness and chroma values are percentages from 0 to 100 and written with a % sign after the number, and the hue is a number in degrees (between 0 and 360). Finally, if the alpha is 1 then it's omitted, otherwise the alpha is a number between 0 and 1 written after a / (slash) character. That way the output from hypicker in oklch mode could be pasted directly into a CSS file.

The number of decimal points for all three (or four if the alpha isn't 1) values is arbitrary, but three decimal points (rounding 59.245502194 to 59.246) is probably a good mix between precision and human-readability. Values with a 0 at the end could be printed with fewer decimals, e.g. 33.42% instead of 33.420%.

NOTE: Three decimal points is more precision than would be needed normally (even the most color-sensitive people would be unable to distinguish between 59.246% luminosity and 59.240% luminosity), but since CSS also allows colors to be used as a basis for calculating other colors (with the oklch(from var(--othercolor) calc(l * 0.9) c h / a) format to, for example, reduce brightness by 10%), rounding error could add up after multiple calculations, so an output with three decimal points is probably a good idea. (I haven't measured this, this is just my rough estimate).

Additional information

Björn Ottoson (the creator of the oklab/oklch color spaces) has posted MIT-licensed C code at https://bottosson.github.io/posts/colorpicker/ to convert between the sRPG and Okhsl color spaces (scroll down to the bottom of the page for the source code, though the entire page is worth reading). This might be useful as a starting point for implementing this feature request. Mr. Ottoson has more posts at https://bottosson.github.io/ explaining why he created the oklab and oklch color spaces, which are great background reading if you haven't encountered them before.

[rmunn]

It might also be possible to have the chroma output (the middle number) be a decimal between 0 and 0.4 instead of a percentage between 0% and 100%. The MDN docs for oklch show C as a decimal rather than a percentage in all their examples, and so do most other sources I've found online so far. (In CSS, a C value of 100% translates to 0.4 so it's a very straightforward conversion). However, for anyone tweaking their CSS to increase or reduce the color intensity — chroma — of a color in their palette, it's much easier to understand how saturated "30% chroma" or "75% chroma" is, whereas it's less immediately obvious that 0.12 means "30% chroma" and 0.3 means "75% chroma". So personally, I'd prefer an output where the chroma is listed as a percentage rather than a decimal value between 0 and 0.4. But perhaps that could be an option: output chroma as a decimal value rather than a percent. I might be in the minority in my preference here.

Something else to note: because chroma is theoretically unlimited, the value could in theory go above 0.4 and therefore the percentage value could be more than 100%. When I played around with the color picker at oklch.com, I found that in practice the chroma will never be above 0.4 (in fact I struggled to find any colors with C ≥ 0.35 that could be shown on any monitor available today, and once you hit C = 0.36 there are no hues that can reach that chroma value). But in theory the chroma value could go above 100%, so for future-proofing, chroma values above 100% should not be considered an error.

[rmunn]

The https://github.com/color-js/color.js or https://github.com/Evercoder/culori Javascript libraries (both MIT-licensed) might make good starting points for this feature: their Javascript code to convert between color spaces would probably be an easy port to C++, and then the RGB values obtained from whatever surface the user clicks on could be run through that conversion function before being output.

Alternately, I could get most of what I want from this already by pasting the RGB values into a CSS file and then running that file through https://github.com/fpetrakov/convert-to-oklch, so this feature request is not really high-priority since there are existing tools that do much the same thing. Still, it would save a few steps if I could simply request oklch output from hyprpicker.

[rmunn]

Actually, come to think of it, a library to convert between color spaces might belong in https://github.com/hyprwm/hyprgraphics.

[vaxerski]

not a bad idea. Feel free to make a MR