Why everyday color tools fail us

Björn Ottosson, the Swedish engineer behind the Oklab color space, spent years working on game engines for titles like FIFA, Battlefield, and Need for Speed. That background shaped his perspective on a problem many developers encounter: the tools we use for color manipulation in software don't match how humans actually see color.

The most common color space, sRGB, was built around how CRT monitors work rather than how the eye perceives color. It relies on specific frequencies of red, green, and blue along with gamma encoding. The result is that intuitive operations often produce surprising outcomes. A gradient between blue and white, for example, turns purple in the middle — a phenomenon that also appears in CIE Lab, a space generally considered closer to human perception. The issue stems from poor hue uniformity: the same hue angle doesn't consistently correspond to the same perceived hue across different lightness or saturation levels.

Perception itself compounds the problem. The eye processes light through many layers of neurons, and context heavily influences what we see — the color of the light source and the background both matter. The infamous "dress" photo is a classic example of how context-dependent color vision can be. Models that attempt to account for all this complexity are known as color appearance models, but they require knowing viewing conditions, which makes them impractical for many use cases.

Building something "okay"

The gap between research and everyday tools persists partly for historical reasons. HSL, developed in the 1970s, was constrained by limited computing power and ended up as a straightforward translation of RGB. Even as processing power grew dramatically, simple tools stuck. Displays also moved forward — modern screens often use wider primaries such as P3 that sRGB can't represent — yet the underlying manipulation tools didn't evolve much.

Ottosson saw this problem firsthand while working in games. He wanted simple operations like darkening a color or shifting its hue, but found every existing color space flawed in some way. CIE Lab handles lightness reasonably but struggles with hue consistency. After leaving the gaming industry for education and consulting, he had time to tackle the problem directly.

Oklab emerged from combining two sources: the lightness and saturation predictions of CIECAM16, a color appearance model, and datasets used to build IPT, a space designed specifically for hue uniformity. IPT's authors ran experiments where participants matched colors across different lightness and saturation levels, producing data on which colors are subjectively perceived as the same hue. Ottosson took those datasets, added the lightness and saturation targets from CIECAM16, and optimized a simple model that balances both strengths.

The name reflects his ambitions fairly literally. "Everything with color is about compromises," he says. Existing spaces weren't good enough for his purposes, and he aimed to make one that was "okay." It's also a nod to humility — research done by a university with a larger participant pool could go further. But for applications on screens, he made the best of available datasets and kept the model intentionally simple.

Rapid adoption across the ecosystem

Ottosson published his work as a blog post, expecting interest mainly from people working with shaders and visual effects. Instead, the post spread through Hacker News quickly. Because the implementation is compact — around ten lines of code — open-source libraries adopted it at remarkable speed.

The scale of adoption surprised him. Chris Lilley of the W3C reached out, asked questions, gave a conference presentation, and championed adding Oklab to CSS. Browsers soon followed. Photoshop also switched its gradient engine to Oklab — all without Ottosson promoting the space further.

What made the space practical rather than just theoretically interesting was its minimal code size and the lack of assumptions about viewing conditions. Oklab is exposure invariant and doesn't account for context like a white versus black background. That's a deliberate trade-off for a model that can work in any environment.

The Okhsl middle ground

For color picking, though, Oklab presents a practical obstacle. The space contains all physically possible colors, but sRGB occupies a strange, non-cylindrical shape within it. Starting from a light, saturated yellow and rotating the hue to blue in Oklab can land you outside sRGB entirely, since such a color doesn't exist on most displays. HSL's geometry — a perfect cylinder where any hue, saturation, and lightness combination is valid — avoids this on sRGB screens.

Okhsl, introduced in a later post, tries to bridge the two. Near gray, it matches Oklab's behavior. Further out, it stretches sRGB's awkward shape into a cylinder, meaning all parameter combinations produce valid colors when manipulating gradients or building color pickers. The trade-off is added complexity — unavoidable, Ottosson notes, when trying to offer the same independent control that HSL provides.

He also adjusted lightness handling in Okhsl specifically for lighter backgrounds like a typical white web page, where differences between dark shades are harder to see. On a black background, those same gradients would look fine, but the approximation introduces other issues. Context always forces a compromise.