dokozero / okcolor

Figma plugin for advanced color picking, with OkLCH, APCA, WCAG and more.

Home Page:https://www.figma.com/community/plugin/1173638098109123591/OkColor

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

OKLrCH for better Lightness?

alexp-ans opened this issue · comments

Hi,

I'd like to suggest implementing OkLrCH space instead of the current OkLCH for more perceptually uniform lightness.
Björn used it in one of these color pickers: https://bottosson.github.io/misc/colorpicker

Middle gray in OkColor is currently #636363, which is darker than the supposed #777777

Also, OkLCH suffers from an extension of dark values near Black, as you can see from this post:
https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
which makes the interpolation from any light colors to black not very uniform.

I hope you will consider this in the next update.
Thank you for such a great plugin!

Cheers,
Alex

Hello @tuananhnp,

Thanks for your message, regarding OkLrCH I agree it would be good to have in the plugin, unfortunately, right now I can't implement it for the following reasons:

The library I use behind for color calculation (CuloriJS) doesn't have OkLrCH (nor OkLrAB), so I would need to code it, and I'm not really a color scientist.

Also, in browser, oklch() doesn't have it neither, so it would be confusing to users if they use OkLrCH colors in browsers to why they don't look the same. For example oklch(50% 0 0) in Chrome is #636363.

However, I agree it could be like an advanced mode in OkColor, but again CuloriJS doesn't have it.

So as I said I'm not a color scientist, but from my understanding, the reason on why we get OkLCH and not OkLrCH outside of Björn's color picker comparison demo, is because OkLCH is better at handling dynamic ranges and larger color spaces in multiple viewing conditions.

This is not the case in his demo where he only uses sRGB with a precise reference white, whereas in browsers, for example, oklch() can be used in any color space, sRGB, P3, AdobeRGB, Rec.2020, etc., in multiple viewing conditions (light or dark room, outside, etc.), and background types, which in this case, it seems that OkLCH was a better tradeoff than OkLrCH.

As Björn explains in his blog article:

"One design decision with Oklab is to use a design that is scale independent. That is, Oklab has no concept of reference white, unlike CIELab for example. In many cases this is an advantage, since it makes dealing with larger dynamic ranges easier.

However, in the context of a color picker with well defined dynamic range and a clear reference white luminance it reduces Oklab’s ability to predict lightness. Therefore, an additional lightness estimate is needed to better handle these cases [...]

Worth noting is that it is not possible to have a lightness scale that is perfectly uniform independent of viewing conditions and background color. This new lightness function is however a better tradeoff for cases with a well defined reference white."

This is also talked about in the article you mentioned.

Note that #777777 is not necessary an absolute middle gray reference, indeed, in this case is the middle gray in sRGB with a certain reference white for certain viewing conditions.

Personally, when working with OkLCH, I find this fact not to be really a problem, because the light to black scale is the same for all tints. Unless of course we try to change the color model of an OkLCH color, for example to HSL, but I don't really recommend it.

Also, in my idea list, there is a task to implement LCH, which has the middle gray to #777777, but I can't give any estimate for now.

And if one day CuloriJS and the browsers implement OkLrCH, I will probably move it to the todo list 👍 .

Hi Doko,

I'm also not fluent in color science. My initial concern was to modifying colors of a design that's supposed to be viewed independently, for optimal effects.

But indeed, no lightness scale is true against various viewing conditions, of which the ideal one could hardly happen.

Now I've understood that the choice for OkLrCH is not that simple.

Thank you for the very detailed explanation!

Best regards,
Alex

You're welcome. I close the issue for now, but as mentioned, if in the future we get browser and library support, I'll see what can be done in the plugin 👍 .