Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oklab: A perceptual color space for image processing

bottosson.github.io

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Oklab: A perceptual color space for image processing

#81

Post by JyrkiAlakuijala »

bjornornorn wrote: post #47
JyrkiAlakuijala wrote: post #32

Earlier quoted context omitted.

One more interesting and substantial difference between Oklab and XYB is that XYB includes biases before the nonlinearity, i.e., one can consider the M1 matrix as a homogeneous matrix. These biases make the receptive model (more) linear close to zero, and the non-linearity ramps up when one goes further into high intensity. The idea there is to model the spontaneous opsin isomerization in the receptors. I believe sRG…

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…

https://gitlab.com/wg1/jpeg-xl/-/blob/master/lib/jxl/opsin_p... has the numbers for sRGB to XYB.

Basically the M1 matrix for linear sRGB [linearR, linearG, linearB, 1] to approximate cone responses:

(I think in this normalization 1 means 250 nits, but not completely sure at this stage of optimizations -- we changed normalizations on this recently.)

M1 = [ [0.300, 0.622, 0.078, 0.0038], [0.240, 0.682, 0.078, 0.0038], [0.243, 0.205, 0.552, 0.0038], [0, 0, 0, 1] ]

then non-linearity by cubic root, in decoding cube, see: https://gitlab.com/wg1/jpeg-xl/-/blob/master/lib/jxl/dec_xyb...

The LMS values after cubic root are coded by this matrix M2:

M2 = [[1, -1, 0], [1, 1, 0], [0, 0, 1]]

In practice Y->X and Y->B correlations are decorrelated, so M2 looks more like this:

M2 = [[1+a, -1+a, 0], [1, 1, 0], [b, b, 1]]

after decorrelations a is often around zero and b is around -0.5.

The first dimension in this formulation is X (red-green), second Y (luma), third B (blueness-yellowness).

For quantization, X, Y and B channels are multiplied by constants representing their psychovisual strength. X and B channels (the chromacity channels) are less important when quantization is low, and particularly X channel increases in strength when more quantization is done.

Cube is beautiful in the sense that it allows scaling the intensity without considerations, but it is quite awful in the near black psychovisual performance. That is why sRGB added a linear ramp, and I added biasing (homogeneous transform instead of 3x3).

Re: Oklab: A perceptual color space for image processing

#82

Post by [deleted] »

JyrkiAlakuijala wrote: post #80
jacobolus wrote: post #64

Earlier quoted context omitted.

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.

[deleted]

Re: Oklab: A perceptual color space for image processing

#83

Post by bjornornorn »

JyrkiAlakuijala wrote: post #81
bjornornorn wrote: post #47

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…

https://gitlab.com/wg1/jpeg-xl/-/blob/master/lib/jxl/opsin_p... has the numbers for sRGB to XYB. Basically the M1 matrix for linear sRGB [linearR, linearG, linearB, 1] to approximate cone responses: (I think in this normalization 1 means 250 nits, but not completely sure at this stage of optimizations -- we changed normalizations on this recently.) M1 = [ [0.300, 0.622, 0.078, 0.0038], [0.240, 0.682, 0.078, 0.0038],…

Thanks!

Regarding: “Cube is beautiful in the sense that it allows scaling the intensity without considerations, but it is quite awful in the near black psychovisual performance.”

Yeah, that is the tradeoff, same for dealing with hdr values. The idea with Oklab is to avoid having to know what luminance the eye is adapted to, by treating all colors as if they are within the normal color vision range basically. Makes it simpler to use and more predictable to use, but makes predictions in the extreme ends worse than it would be taking knowledge of the viewing conditions into account (given that you can do so accurately)

E.g. linear ramp for near black values would not be good if you are in a dark room, only viewing very dark values full screen on a monitor (so there isn’t anything bright around to adapt to)

Re: Oklab: A perceptual color space for image processing

#84

Post by jacobolus »

alok-g wrote: post #61
smallnamespace wrote: post #59

Earlier quoted context omitted.

If you're trying to show raw space RG (50, 50), then when you show (100, 0) and (0, 100) in adjacent pixels, there are exactly 50 * 2 units of light distributed over each pair of pixels, so your eyes will see (50, 50) if the pixels are small/far enough. Another way to put this is that dithering works because of physical blending of photons due to an insufficiently sharp eye lens before perceptual mechanisms in the br…

You are taking the example when dithering is done independently for each color channel. Dithering can also be done across color channels, which can be useful for displays with more than three primary colors. Even in those cases, I found dithering to work better in the physical space, and not in perceptual space. I am trying to understand why. Further, the question still remains why is it that mixing of photons spatia…

Dithering is best done linearly with respect to light intensity.

But if you zoom in enough, any smooth curve looks linear.

Re: Oklab: A perceptual color space for image processing

#85

Post by jacobolus »

mark-r wrote: post #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.

What is the goal of your hue shift?

If your goal is to otherwise preserve color relationships, then you should use a perceptually relevant color space.

But maybe you have some different goal...?

Re: Oklab: A perceptual color space for image processing

#86

Post by mark-r »

jacobolus wrote: post #85
mark-r wrote: post #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.

What is the goal of your hue shift? If your goal is to otherwise preserve color relationships, then you should use a perceptually relevant color space. But maybe you have some different goal...?

Sometimes the goal is just to change the color of an object while retaining the shadows, highlights, and textures. Suppose you had a picture of a blue car and wanted to know what it would look like in yellow.

Re: Oklab: A perceptual color space for image processing

#87

Post by jacobolus »

mark-r wrote: post #86
jacobolus wrote: post #85

Earlier quoted context omitted.

What is the goal of your hue shift? If your goal is to otherwise preserve color relationships, then you should use a perceptually relevant color space. But maybe you have some different goal...?

Sometimes the goal is just to change the color of an object while retaining the shadows, highlights, and textures. Suppose you had a picture of a blue car and wanted to know what it would look like in yellow.

Personally I use this tool I built as a Photoshop action over a decade ago, https://www.hcs.harvard.edu/~jrus/colortheory/jl.html (see the animation at the bottom showing almost precisely what you are asking about) Initial discussion: https://www.ledet.com/margulis/2010HTM/ACT08-Jacobs_Ladder.h...

An HSV hue shift (or whatever similar thing you are thinking of) yields horrible results in this use case.

Re: Oklab: A perceptual color space for image processing

#88

Post by dimovich »

jiggawatts wrote: post #3

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…

Another option for generating gradients is using cosine based pallets [1]. And a nice implementation [2].

[1] https://iquilezles.org/www/articles/palettes/palettes.htm

[2] https://docs.thi.ng/umbrella/color/#cosine-gradients

Re: Oklab: A perceptual color space for image processing

#89

Post by mattdesl »

bjornornorn wrote: post #78
raphlinus wrote: post #70

Earlier quoted context omitted.

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.

I added Oklab to the Observable notebook. With the current set of palettes, it produces results that are very similar to Lab, but I imagine with some specific color/hue transitions Oklab will outperform Lab.

https://observablehq.com/@mattdesl/perceptually-smooth-multi...

Re: Oklab: A perceptual color space for image processing

#90

Post by mark-r »

jacobolus wrote: post #87
mark-r wrote: post #86

Earlier quoted context omitted.

Sometimes the goal is just to change the color of an object while retaining the shadows, highlights, and textures. Suppose you had a picture of a blue car and wanted to know what it would look like in yellow.

Personally I use this tool I built as a Photoshop action over a decade ago, https://www.hcs.harvard.edu/~jrus/colortheory/jl.html (see the animation at the bottom showing almost precisely what you are asking about) Initial discussion: https://www.ledet.com/margulis/2010HTM/ACT08-Jacobs_Ladder.h... An HSV hue shift (or whatever similar thing you are thinking of) yields horrible results in this use case.

That example looks like it's working directly with RGB, which I expect to be correct. I've also seen it work well in HLS. But I worked on a tool where we were told to change from HLS to CIELab because it would be better, and it turned out to be much worse in practice.
Post reply on HN