Live data from Hacker News

Oklab: A perceptual color space for image processing

bottosson.github.io

71–80 of 94 posts

Re: Oklab: A perceptual color space for image processing

#71

Earlier quoted context omitted.

Chromatic adaptation is definitely one of the trickier questions in color management. Here's my take on it. For the most part, when looking at a monitor, chromatic adaptation is pretty good. In other words, RGB #FFFFFF looks white, not light blue, and #808080 looks gray, not bluish-gray. It does start falling apart when you mix different lighting, for example holding a white piece of paper to the screen under normal…

D65 is the sRGB whitepoint mostly because it is the CIE Standard D Series Illuminant, i.e it is a Standard illuminant like A and should be use preferably when typical daylight modeling is required. A display by tuning of the primaries intensity can match a lot of different whitepoint, reaching anything from D50 to D90 is certainly doable.

D50 and D65 are the 1960s replacements for illuminants B and C, which were introduced along with the CIE standard observer in 1931.

Illuminant A is a black body radiator that approximates an incandescent light bulb. Illuminants B and C are attempts to approximate daylight by putting a colored liquid filter in front of the black body radiator (or incandescent bulb). Illuminant B is a simulation of tropical noon daylight, while Illuminant C is a simulation of average daylight at a higher latitude (more contribution from the sky, less from direct sunlight).

Illuminant C was widely used in colorimetry, but it didn't match real measured daylight spectra especially closely, so the D illuminants are a replacement based on some physical measurements taken in Rochester (where Kodak was based) and London. Colorimetric applications that previously used illuminant C mostly switched to D65 instead.

(Note that real outdoor daylight spectra vary dramatically depending on place, time, and weather conditions.)

For details, see https://en.wikipedia.org/wiki/Standard_illuminant

> reason D65 is chosen for the sRGB white point is that it is fairly accurate, in other words it's pretty close to the actual white point of the monitor I'm looking at now (Dell P2415Q).

There is also influence the other way. Monitors have a D65 white point to match the spec.

Re: Oklab: A perceptual color space for image processing

#72

This is a tour de force of colour theory, and should be mandatory reading for anyone serious about computer colour! Björn Ottosson not only did some mighty fine work, producing a simple equation that produces smooth colour gradients, but he "showed his work" too. Instead of just journal references, he littered this page with incredibly useful hyperlinks to difficult to find things such as the raw data for the Munsell…

Author here. Wow, thanks a lot! If anyone has any questions feel free to post here and I can try to answer. I have another post that goes into more detail onhow software often gets color wrong: https://bottosson.github.io/posts/colorwrong/

I have suggestions for a color picker. It's definitely non-traditional.

Instead of a continuous gradient for the color, show patches of color in a randomized order. Display the colors over top of grayscale gradients of different sizes. This helps to deal with the trouble of human perception being affected by background and by solid angle. You might also want to consider showing the new color right over or around an image of the user's choice.

For example, on a small screen, you might have a 256x256 patch on a 512x512 grayscale gradient for the currently selected color, and numerous 16x16 patches on 32x32 gradients for the choices that the user can make.

With each click on a choice, the whole array of choices is redone.

Available choices are provided as variations of the current choice and any colors that might have been bookmarked. Take the current choice, and vary the hue. Take the current choice, and vary the saturation. (including the negative extreme, positive extreme, and grey) Take some properties (hue, saturation, etc.) from the current choice, and others from a recent bookmark. Probably also throw in a 3x3x3 sRGB to make dramatic changes simple. Be sure to include everything that is within 2 or 3 units of the current choice in sRGB. In a plane that slices through the current selection and the grey line, provide choices that run along lines from the current choice in 4 different directions: black through the current selection until out of gamut, white through the current selection until out of gamut, along the saturation axis both directions, and along the L axis parallel to the grey line.

So with each click, you head in the direction you prefer.

Re: Oklab: A perceptual color space for image processing

#73
post #69

Obligatory XKCD... https://xkcd.com/927/ [FWIW, thanks to prove the HN crowd has strictly no sense of humor what-so-ever...]

It's not that we have no sense of humour, it's that: a) Almost all of us have seen it before. b) A comment with just an opaque link doesn't really add anything to the conversation. c) That comic doesn't even apply in this case, as Oklab is not trying to be a universal standard covering all use cases. Its intended purposes are quite specific and different from the other colour spaces.

It's not nearly as clear as you purport, and thus, the link is funny and appropriate - there's nothing on that page to suggest its _not_ the best for all use cases - the sum total of its argument is its better in every case.

However, the data isn't 100% there if you work in the spaces, i.e. I'd want to understand more how the CAM16 gradients were generated (CAM16 has two correlates for lightness and another three for 'color', saturation, colorfulness, and hue. CAM16UCS 'only' has colorfulness. How could the CAM16UCS gradient get 'saturated' more quickly?)

Re: Oklab: A perceptual color space for image processing

#74
I've seen CIELab used to do color transformations, and it has a problem. This color space looks like it will suffer from the same problem.

If you try to shift hues, keeping a constant luminance causes a problem. You can't transform a bright blue to a bright yellow, because the luminance of blue is considered much lower than yellow. The best you'll get is a very dark brown.

Re: Oklab: A perceptual color space for image processing

#75
post #57

Earlier quoted context omitted.

Author here. Wow, thanks a lot! If anyone has any questions feel free to post here and I can try to answer. I have another post that goes into more detail onhow software often gets color wrong: https://bottosson.github.io/posts/colorwrong/

Your OKlab vs HSV plot is useful, but left me curious what that would look like in CIE L c h just varying hue. It seems the most direct comparison to me, just workign in LCH vs your proposal and the post isn't super clear about the benefit.

There are a two different CIE LCh color spaces: they are cylindrical samplings of CIELAB and CIELUV, similar to how Oklab can also be sampled with cylindrical coordinates

The comparisons with CIELAB and CIELUV are using LCh coordinates. That’s how hue and chroma predictions are made using those spaces.

Re: Oklab: A perceptual color space for image processing

#76
I've noticed for a long time that in a color wheel, Cyan Magenta and Yellow are much brighter than Blue Red and Green. A couple of years ago it finally dawned on me why that was - the way our monitors are designed, Cyan Magenta and Yellow are producing twice as many photons! They each produce full intensity on two primary colors instead of just one. They don't look fully twice as bright because of the eye's non-linear response, but it's definitely a noticeable effect.

Re: Oklab: A perceptual color space for image processing

#77

> Converting from linear sRGB to Oklab With public domain C++ code! This is incredibly useful to me as a Unity developer. Can almost be plugged right in to C# & Unity Colors. Could be used for interesting real-time color effects. One of my favorite simple things to do in HSV is to animate the hue. This could be used to do something similar, but across that more attractive Oklab gradient. Great post.

You can change hues in RGB without having to use HSV. See https://stackoverflow.com/a/8510751/5987

Re: Oklab: A perceptual color space for image processing

#78

Great work, kudos to the author. Keen to try this in my own applications. I wonder how it fares with cubic spline gradients, I noticed some odd hues/tones depending on the colour space and Oklab might solve some of that. [1] [1] https://observablehq.com/@mattdesl/perceptually-smooth-multi...

I'm very curious about this too. I'm going to seriously consider this color space, as well as cubic splines, as native gradient types in piet-gpu, because I think it's likely we can see higher quality at modest GPU shader cost.

Nice! Definitely the the type of use case I had in mind.

Re: Oklab: A perceptual color space for image processing

#79

Really cool! Do I understand the process for using this correctly? Take something in another color space, convert it to oklab, then perform whatever editing operations you want on the values, convert it back out to whatever color space for the file format you are using, and the results will be more accurate?

Yes, exactly. The results will be more accurate as in closer to perception of light (for rendering for example you would want a linear color space)

Re: Oklab: A perceptual color space for image processing

#80

Earlier quoted context omitted.

Not that familiar with XYB and its properties. Is there anywhere I can read more? Found some specifications, but not anything on its properties. I think this might be a case where the requirements for image editing and image compression are different. For image editing, especially when working with HDR images, I think it is better to just have a simple power function, since this makes less assumptions on the exact vi…

I would consider just continuing to use the CIELAB adjusted cube root function, with a linear part near zero. It has been used widely for 45 years and people understand it pretty well. It is plenty fast to implement (just takes one extra conditional move or the like and one FMA).

We don't need to use something just because it is old. CIELAB is based on 2 degree samples of color. Colors work differently at smaller angles due to the different densities of receptors, particularly the larger size and lower density of S receptors. Pixels on most recent monitors are about 0.02 degrees, 100x smaller in angle, 10'000x smaller in area than what the old color research is based on.
Post reply on HN