A (Even) More Practical Lightness Estimate for Oklab

 

An Short Introduction to Color Spaces

Human color perception is extremely complex, yet we mostly interact with colors through simple mathematical abstractions in the digital realm, the most known being RGB – splitting a color into three numbers for components of red, green, and blue light respectively. This roughly aligns with the sensitivities of the three types of cone cells in our eyes, and displays use these colors in their subpixels for the same reason.

However, the numerical representation that arises from this is not very useful in accurately predicting how a color will be perceived, in particular how light or dark it is, but also how colorful (or more precisely chromatic) and what hue. But these are the dimensions we actually use to talk about color. How different we perceive two colors to be is also only very loosely related to the difference in their R, G, and B values.

For this reason, color scientists have developed so-called uniform color spaces that attempt to represent colors in these three dimensions (or instead of chroma and hue, redness-vs-greenness and blueness-vs-yellowness) and additionally so that the geometric (Euclidean) distance in this space is as close as possible to the perceptual difference between colors. The latter is fundamentally impossible, as for three colors, the perceived distance between two of them can be larger than the sum of their distance to the third, but approximations have improved over the years and the former is achieved quite well by now.

These uniform color spaces are extremely useful for choosing colors for design, creating color palettes, generating pleasing gradients and much more.

The Problems With Available Options

The remaining challenge is primarily to bring together hue linearity (keeping constant perceived hue under changing lightness and chroma) and a suitable rate of change of lightness from dark to light, determined by the transfer function used to transform from the linear CIE XYZ color space, as no uniform color space has had both so far.

The CIELab lightness L* for example is generally said to predict lightness well for achromatic colors (grey tones from black to white) for most applications, but has very bad hue linearity in some regions. And color spaces like Oklab and ITP have good hue linearity but are not optimized to predict lightness well in typical use cases. These latter two also share an unusually simple mathematical construction, especially for the quality of their predictions.

Figure 1: Linear gradients from black to white, blue to black and yellow to blue in various color spaces. The black to white gradient highlights even subtle differences in the transfer function, while the gradients containing blue showcase the hue-nonlinearity (a shift towards purple) often present in this hue region.

Figure 1 shows some of the issues commonly encountered by comparing linear (in the respective color space) gradients. For achromatic colors, we can see the largest deviation from CIELab lightness L* in Oklab. On the other hand, CIELab, CAM16-UCS and sRGB have varying degrees of purple tones in their blue gradients due to their lacking hue-linearity, on top of an undesirable dip in lightness on the blue side of the yellow-blue gradient in sRGB. Oklab on the other hand performs better here with no visible purple shift.

If we already have all the ingredients, an obvious approach would be to attempt to combine the desirable aspects of two color spaces – and exactly this has been done before. Once for example by James O’Leary at Google, who created the HCT (hue, chrome, tone) color space by simply calculating the lightness L* of CIELab and hue and chroma of CAM16-UCS (which is the best at measuring distances) for a color independently. This has the significant downside of having to search for the matching lightness in CAM16-UCS when one wants to convert back to any other color space, which is necessary for displaying the color, a problem for real time graphics applications. And I’d personally argue that hue linearity is more important than uniformity of distance for most applications. However, access to the exact L* allows the use of many tools and guidelines developed with CIELab.  The creator of Oklab, Björn Ottoson, has also published a way to bring the lightness estimate of Oklab closer to that of CIELab by applying a second transfer function to it after conversion (this keeps all other desirable properties intact). He called the resulting lightness estimate Lr, and the associated new colorspace has often been termed Oklrab accordingly.

We can do better though.

The Math

CIELab’s lightness L* is derived from the CIE XYZ color space as $$ L^{*} = 116 f(Y/Y_{w}) - 16$$ $$f(t) =  \begin{cases} \sqrt[3]{t}, &\text{if } t < \left(\frac{6}{29} \right)^3 \\ \frac{t}{3} \left(\frac{6}{29} \right)^2 + \frac{4}{29} \end{cases}$$ where the Y value of the white point (almost always D65) Yw is by definition 100. Oklabs lightness is also derived from XYZ and defined as $$L = M_{2, 1*} \left(M_1 \begin{pmatrix} X \\ Y \\ Z \end{pmatrix} \right)^{\frac{1}{3}}.$$ Importantly, the entries in the matrices M1 and M2

mean that Oklab’s lightness is also mainly dependent on Y with a smaller contribution of X and almost none from Z. As one of the constriants of Oklab’s derivation they were balanced precisely so that for a white point of D65 normalized to Y=1, the lightness of an achromatic color is the cuberoot of Y down to about floating point errors of 1e-7. This likely motivated the use of an asymptotically linear function with a bump close to zero as the corrective transfer function for Lr in Oklrab. Figure 2 shows the resulting overall transfer function as well as those of the original Oklab and CAM16-UCS.

Figure 2: The normalized transfer functions of various relevant color spaces. Oklrab’s is visually indistinguishable form CIELab’s, but Oklab and CAM16-UCS are noticeably different.

But since we know Oklab L is the cuberoot of Y for achromatic colors, we can simply cube L, plug it into the formula for L* as Y and get back exactly L* for these colors. To match Oklabs usual scale between 0 to 1, we need to then also divide by 100. I’ve termed the resulting color space Okslab for “standard(ized)” or “star L”. While the difference to Oklrab is relatively small, Oklrab’s lightness is not truly identical to CIELab’s, while this new color space is effectively exact. This becomes apparent when plotting only the deviation from L* as in Figure 3.

Figure 3: The deviation of the predicted lightness of various color spaces from the lightness of CIELab. The initial linear segment of CIELab and Okslab increases slower than those based on powers less than one.

So far, we’ve only considered achromatic colors. Since CIELab’s lightness depends only on Y for every color and Oklab’s incorporates X and to a lesser degree Z as well, moving off the grey axis leads to deviations even with the perfectly aligned grey axis of Okslab.

Figure 4: The deviation of the lightness predicted by Oklab from that predicted by CIELab for an 8x8x8 grid of sRGB colors. They appear to mostly consist of a shear in a single direction, specifically along tha a axis for CIELab.