Saturate is implemented for color spaces without saturation property

[frozolotl]

I am currently in the process of deciding how I want to improve Typst's color.saturate function. There, we have support for a few color spaces, but in this context most importantly: Oklch.
It would be quite easy to implement color.saturate by default in terms of Oklch, but I'm not sure that's the best idea because Oklch does not have a saturation value, but instead uses chroma.
For that reason, I am thinking it would be best to add Okhsv/Okhsl support to Typst. After all, these color spaces do saturation with the best tradeoffs from what little I researched.

Now, I noticed that palette::Saturate is actually implemented for Lch and Lchuv, two color spaces that only have chroma attributes, not saturation.
The same trait is not implemented for Oklch, however.
I am thinking that perhaps the difference between chroma and saturation might not matter when scaling that attribute?

So, what I am asking:

1. Why do Lch and Lchuv implement Saturate?
2. If this was by design, why does Oklch not implement it?
3. If you like, how would you solve the problem I gave in the first paragraph?

[Ogeon]

Hi, the issue isn't actually the chroma, but whether or not it has an upper bound. Saturate is loosely defined to take the color further from grayscale, so saturation, chroma and colorfulness all fit the definition. They are tightly related and sometimes used interchangeably.

The oversight lies in the design of the Saturate trait, which has a function that takes the saturation/chroma/colorfulness (i.e. distance from grayscale) relatively closer to its maximum. This is hard to do if a color space doesn't have a well defined maximum.

• Lch gets its maximum from the conventional bounds of Lab (for squeezing it into three i8 values), but they are also formally unbounded. This was a misunderstanding.
• Lchuv has an upper bound, but it varies with the hue.
• Oklch will need an arbitrary upper bound and one could say that it already has been done in the rand support. Slippery sloping from there to Saturate wouldn't be too far, but it's not the "proper" way. 🤔

For Typst (looks like a neat application, by the way!), I think you need to ask yourself a couple of questions:

1. What type of saturate function do you want? Absolute or relative? If your answer is "absolute", you don't actually need the Saturate trait. It's just color.chroma += x; and maybe some clamping. 😉
2. If you use Oklch or Lch (or their relatives), how do you want to handle colors outside of sRGB? Okhsl and Okhsv were made to make color picking more intuitive than with Oklch, and they include a solution to that problem by stretching the sRGB gamut and having it as the upper bound.

I'm not sure if I managed to answer your questions yet, but I hope it's a step forward.

[frozolotl]

Thanks for your quick and elaborate reply! It definitely helped clear some things up :)

I was already thinking about removing Typst's limit where colors have to fit into the sRGB gamut.
Because I doubt these conversions occur very often in a typical Typst program, gamut mapping using Okhsv seems like the preferable option due to its better results.

I think it would be best if I implemented both absolute and relative saturate, which the user can decide between using an optional named argument.
Defaulting to relative and Okhsv might be most in line with users' expectations I imagine.

Honestly though, I don't know for sure what the most desirable behavior would be in this case.
In Typst, it will likely be used to fine-tune colors directly in the editor. Maybe some light image manipulation in the future, once such a feature was implemented?

[Ogeon]

I don't think I can give you a definite recommendation, but handing over the choice to the user may be a good option. That's what I try to do. 😅 I can't have too strong opinions without limiting something. Otherwise, we wouldn't have this conversation. 😁 I imagine that you are in a similar spot, but you have a more specific use case. This is a trade-off situation, so someone has to choose.

The HSL, HSV and HWB models are at least familiar in graphical color pickers. I can't say if relative or absolute saturation is more common, though. I asked myself the same thing and decided to have both when I didn't find a good answer.

If you still want to pick only one option, I think you just have to try them and see what works best for this kind of application, then go with it. I can at least say that Okhsl is probably the closest analogue to Oklch, though. Both have their fully saturated colors somewhere around half lightness, but vary in wobbliness.

The way (de)saturation is implemented in palette is relatively simple, once you decipher the macros, so you could copy the algorithms if you want and use any space. I will eventually redesign the Saturate trait to fit more color spaces, but that will need some more thinking.

[Ogeon]

Just out of curiosity, how did it go? Did my rambling help you decide on something? 👀

[frozolotl]

I kind of decided to postpone the change to work on slightly more important things. (There is not a single use of color.saturate and color.desaturate on GitHub)

I did however remove restrictions to Oklab's and Oklch's chroma component, as well as switch to using Okhsv for conversions from Oklab and Oklch to other color spaces.

Once I have implemented another feature though, I think I will focus on color saturation again. That will probably look like I described earlier, but I'll probably ruminate a bit more.

[Ogeon]

Alright, yeah, I suppose it doesn't hurt to let it bake for a bit more. 🙂 Feel free to get back if you find a nice option that works well with the unbounded chroma, if you want. I'm always interested in actual use cases and solutions that can guide the library design.

And it's cool to see that Typst has gotten some more attention recently. 👀