Science evolves, based on experiences, experiments, and new insights. And that includes color science. Although the use of CIELab color description is fundamental to current color specification and reproduction, CIELab is ‘icky’, as John – The Math Guy – Seymour eloquently described it. Which means: it can be improved. One of the alternatives is OKLab, and it’s relative OKLch. And the latter one is enthusiastically embraced by the web… So, when will print switch to OKLab and OKLch? Here’s why we should, and how we could proceed.
CONTENTS: Which issues with ‘regular’ CIELab? | Enter OKLab and OKLch | Beyond sRGB… | Broader support? | What’s holding us back? | Why is this important? | Updates
I must admit that I only came across OKLab and OKLch recently. The first time was last year, when I ran into Steve Upton from Chromix at drupa. In his ‘Lab is icky’ video (I’ll share it at the end of this article), John Seymour also mentions it, as a possible solution for the ickiness of CIELab. And dr. Andreas Kraushaar from FOGRA mentioned it in a LinkedIn chat. So, I was intrigued, given the issues with ‘regular’ CIELab.
Which issues with ‘regular’ CIELab?
You might wonder what the issue is with ‘regular’ CIELab. Well, if you like blue, you probably will have encountered it: the infamous blue-to-purple shift. You can see it from time to time in newspapers, where RGB-colors are converted to a rather small newspaper gamut. I’ve published an article on that specific case some five years ago.
But it’s not limited to small CMYK gamuts like newspaper, this can happen with any transform of blue images from RGB (e.g. AdobeRGB) to CMYK (e.g. PSOcoated v3). Here’s a picture I took several years ago. Really nice blues! But when I try to convert it to CMYK, the result is plainly awful. More than just ‘icky’.
This was also the case when I published a book with pictures made during the first COVID-19 lockdown. It took a long search to get this printed the way I wanted. I wrote a few articles about it, one of which shows the final result, and another interesting one is why this matters for photo books. And it can even be more prominent than the example above, as I showed in this article, published 5 years ago.
But you can also see it when defining gradients… a blue gradient turning purple in some shades. The picture below shows this, I’ll get back to that later on!
To get to the core problem, check out the video by John Seymour below. He explains it very well, as he always does.
Next to CIELab, there is also CIELch, which is a mathematical transformation of CIELab. The interesting thing about CIELch is that it’s much easier to understand and could make, e.g., color management easier (check out this article). But, being a relative of CIELab, it suffers from the same issues… In an ideal world, the perceived ‘color’ (color category) would not change when the hue of that color changes. You can see that in diagrams, gradients of a particular color are straight lines in a CIELab or CIELch 2D plot. But that’s not the case: a constant hue in CIELch is a curved line.
Enter OKLab and OKLch
Given that CIELab is not perceptually perfect, several attempts have been made to develop better models. And one of these is gaining traction: OKLab and its relative OKLch. This is a project by Björn Ottosson, you can read the whole rationale behind it in a post he published in December 2020. Since then, it has gained traction, with the most essential feat: acceptance by the World Wide Web Consortium (W3C) and being a part of the CSS 4 specifications. BTW: here is a talk during W3C workshop that covers OKLch.
The major browsers (Chrome, Edge, Firefox, and Safari) support OKLch. And the web design community is starting to see the advantages of OKLch.Especially related to web design, you can see many tools supporting OKLch. Here are some examples of color pickers:
- https://oklch.com/ (and the source files on GitHub)
- https://oklch.eerolehtinen.fi/
- https://oklch.eu/
If this all is still too abstract for you, let’s take a look at a few very simple examples.
The original post by Björn Ottosson contains a visual comparison of blue gradients in different color spaces. I guess you will see the issue and the solution.
Another example is from a website called Evil Martins – I love that name. In an article titled “OKLCH in CSS: why we moved from RGB and HSL”, they show how OKLch makes it much easier to define certain color variants. Check this example of buttons.
And they also made a comparison of a few gradients.
Beyond sRGB…
The article by Evil Martians shows also another fact the web community seems to appreciate about OKLch: it is device-independent. In case that doesn’t ring a bell, that’s one of the fundamentals of color management: being able to describe a color in a way that is not linked to a specific device (or device category), in an independent way. Until the appearance of OKLch, colors on the web were mainly described as sRGB values, often written in the shorter hexadecimal way (HEX).
But now, with OKLch, they are no longer limited to that rather small gamut of sRGB. With more and more monitors, TV sets, smartphones having a wide gamut (e.g. P3), meaning: more colors, Evil Martians sees the following two advantages for web design:
- Some of these new colors are more saturated. Thus, you can produce more eye-catching landing pages.
- The additional colors give your designers more flexibility with palette generation for their design systems.”
And a 2023 article on Medium, titled Advancing Color Coding with OKLCH: A Leap Beyond RGBA concluded the following:
“OKLCH emerges as a powerful color encoding alternative with its intuitive syntax, automatic palette generation, enhanced color reproduction on modern screens, and predictable contrast. By adopting OKLCH, designers and developers can leverage these benefits to create more visually appealing and accessible digital content, making it a worthy successor to the conventional RGBA system.
The transition towards OKLCH is more than a mere change of syntax; it’s about embracing a tool that is attuned to the evolving needs of digital color representation and accessibility.”
In case you missed it, about a year ago I already discussed the wide availability of wide gamut displays, the fact that sRGB is no longer the most common color gamut. Even recent office monitors have a wider gamut, including the cheap 27″ 4K monitor I’m using at the office, that one has a DCI-P3 color gamut…
Broader support?
When digging a bit deeper to check which software applications support OKLab and/or OKLch, it seems this is still quite limited. But… there are some interesting cases…
A very interesting one: Adobe supports it in some particular cases. The most important one: the way they calculate gradients. calculate gradients. And this blog post mentions that they have added OKLch to their color picker components in React Aria and React Spectrum. Why? “Our algorithm for generating color descriptions works in the OKLCH color space, recently standardized by CSS. This color space offers the advantage of uniform lightness across all hues, unlike HSL, where hues like blue appear significantly darker than hues like green or yellow at the same lightness value. “
However, in well-known Adobe CC applications, like Photoshop or Illustrator, you will not find an OKLab or OKLch slider yet.
Also, an important one: Little CMS. You may not know this, even though you may be using this color management system: it’s integrated in multiple software packages. There have been questions from users to support OKLab / OKLch for several years, and, e.g., this tools has been created.
A user-focused piece of software that can use OKLch is Krita. I had never heard about this before, but this is a free software application for ‘digital painting’ and 2D animation. And it now has a plugin for OKLch.
And last one: Chromix ColorThink. Version 4 includes OKLab. I had the chance to play with it. The left image below shows how a perceptually uniform blue to white gradient looks like in the 3-dimensional CIELab color space. That’s not a straight line, isn’t it? The left image shows the same gradient, but in OKLab. That’s what it should look like!
BTW: Chromix ColorThink is a really cool tool! If you are in to color, as a teacher, researcher or color nerd, you need to check it out. One of the fun things in the 3-dimensional plots is that you can open an image and check how it’s converted from one color space to another. The left image below shows a part of the nice blue image I showed above (a downsampled version, to limit the number of points). The right image shows vectors, showing the transformation from AdobeRGB to PSO Coated v3…
There is one last tool I want to mention: the – excellent – ColorTools add-in for Microsoft Excel, created by Edgardo García. At this moment it doesn’t support OKLab / OKLch yet, but he did tell me he intends to add OKLab, OKLCh, IPT and Jzazbz support. I’ll certainly update this page and mention it on LinkedIn when he has updated this add-in. If you don’t know the ColorTools yet, you do need to check it out! It’s great, and it’s free…
Where to start?
Software developers should certainly look into it. It shouldn’t be that hard to support OKLab / OKLch: it’s a mathematical transformation from one color space to another. And when that transformation is done, all kinds of actions become much easier. Consider converting an image from a wider gamut (e.g., AdobeRGB) to a smaller print gamut (e.g., PSO Coated v3). These used to be complex translations, due to the ‘icky’ behavior of CIELab. With OKLab and OKLch being much more conforming to human perception, reducing the saturation of a color to let it fit the target gamut (that PSO Coated v3), it might be sufficient to decrease the c (chrome), there would not be any reason to touch the value of h (hue).
What would also become much easier is the delta E calculation. Did you ever check the formula for the delta E 2000 calculation (dE00)? (In case you want, here it is) That’s extremely complicated, well, at least to me. The reason why it’s so complicated is again those errors in the fundamentals of CIELab / CIELch. By eliminating those errors, the dE calculation becomes very easy, just like the original dE76 calculation was.
Once many or most applications support OKLab / OKLch, we could start using it in color libraries and brand color guides. And tolerances could be specified in another way, now that hues, chroma and Lightness in OKLch are conforming better to human perception. I would love to see research being done to define how ordinary humans perceive color differences and brand color transformations (e.g., the same logo in a commercial on a wide gamut TV set versus the same logo in a newspaper ad), and break those difference up in the three elements: L, c and h. I bet we are far more tolerant to changes in saturation than changes in hue.
What’s holding us back?
Aha, the million-dollar question… The first response will probably be that systems need to be changed and that costs money. Yes, a switch to OKLab / OKLch will come at an upfront cost. But… you need to see this as an investment: it will result in savings. Encoding color transformations will become much easier and much faster. They will also become more reliable, resulting in fewer complaints. And we could see a real convergence of how print and the web treat color: in a device-independent way, based on a perceptually OK color space.
But, some might argue, it’s ONLY an OK color space. Shouldn’t we wait for a PERFECTLab / PERFECTLch? And what about the other alternatives? Well, there will always be opportunities to improve, but at this moment, there is a move in the world of the web towards OKLab and OKLch. In my opinion, it would be very beneficial if the printing industry rode that wave and profited from a joint acceptance of these new possibilities.
And then there is the biggest possible issue: job protection… Some color experts, who have invested years, if not decades, to master the intricacies of CIELab/CIELch, might see this ‘competitive advantage’ being significantly reduced. And these color experts might significantly influence the decision to support something new like that, OKLab and OKLch… I hope this is not the case, they will still have the rest of their color knowledge as their competitive advantage. But given some anecdotes from the past, job protection can endanger any evolution or improvement…
Why is this important?
CIELab is ‘icky’ and you risk seeing that every time you work with the color blue.
OKLab and OKLch solve that problem, for the most part. The web is embracing these new ways to describe color. If the printing industry doesn’t follow, we will miss an interesting opportunity. And in a few years, we might even see disruption coming from tools originally geared towards web design.
What do you think? Did I miss anything? Which is of course possible: it’s a rather complex topic. And please share your ideas about OKLab / OKLch in a comment or join the discussion on LinkedIn! And if you would like to read what Google Gemini Deep Research says, here is a 14 page report.
PS: here is John Seymour explaining why CIELab is ‘icky’.
UPDATE 11/05/2025: On LinkedIn, John Seymour made some excellent comments. Since they are linked tightly to the goal of this article, I’ll add them here, alsof for future reference:
“Thanks for bringing this up, Eddy.
There are a lot of issues with CIELAB. One, as pointed out in Eddy’s blogpost, is that CIELAB hue angle does not always correlate with our visual perception of hue — two colors that CIELAB thinks are the same color might not bee the same hue for a person.
A second problem is that computing the CIELAB values under a different illuminant does a lousy job at predicting the actual change in visual appearance.
A third problem is more well known. CIELAB is not “perceptually linear”, that is, equal steps in CIELAB do not correlate with equal steps in visual perception. If this is a leaky pipe, then the modern color difference equations are duct tape, and CIEDE2000 is a bucket under the leaky pipe.
OKLab fixes the first problem. That’s cool.
I think that OKLab partly fixes the second problem.
OKLab is slightly worse that CIELAB at the third problem, according to a recent paper from Ronnie Luo and a bunch of other smart guys. This makes OKLab absolutely unacceptable for any industry that relies on color differences.
OKLab was designed around the idea that the color calculations had to be fast. This makes sense when you are dealing with millions of pixels in an image. But is sacrifices one of the most important things that we rely on CIELAB for – delta E.”
So, to conclude: there is room for a PERFECTLab and PERFECTLch… Who will take the lead in this?
Be the first to comment