Live data from Hacker News

Oklab: A perceptual color space for image processing

bottosson.github.io

61–70 of 94 posts

Re: Oklab: A perceptual color space for image processing

#61
post #48

Earlier quoted context omitted.

Indeed, I have observed for it to work better in the raw space. Even going to linear gamma space seems to hurt. However, it's not clear to me why should this be so. For a given wavelength, I would understand that mixing in physical space would be better, i.e., this may apply to lightness. Why should it not work better when applied more generically in a perceptual space (Note: I have worked with displays with more tha…

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 spatially as you explained works better imperceptible pixels, and yet we need these non-linear color spaces when having larger areas.

Goes without saying that the intensity hit for 50 need not be the midpoint of that hit for 0 and 100 given the gamma curve, and actual mapping of the value to intensity for the pixel.

Re: Oklab: A perceptual color space for image processing

#63

This is some great work. The notable point here is that the work is done by a Computer Graphics Programmer using Open Source Free software (colorio and colour-science both for Python ) and not a Researcher using Closed Source Commercial software like Matlab.

I'm not sure why all these are capitalized as some sort of formal titles, but matlab is very rarely used in computer graphics. Computer graphics is mostly fairly simple math that needs to scale well and not have edge cases. Some papers have had their algorithms in matlab but it is the exception in research and basically never used in any sort of production sense, because you would just have to port it to C++ to use i…

[deleted]

Re: Oklab: A perceptual color space for image processing

#64

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…

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).

Re: Oklab: A perceptual color space for image processing

#65

> 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.

It looks really cheap, you could easily hue shift every pixel in the game with this. One trick I've used in the past is using the alpha channel to mask multiple hue shifts in a shader to give a lot of variations. Eg 0 = shift A, 0.5 = don't shift, 1 = shift B. That way you can make eg leather armor with metal attachments, and tan or fade the leather and swap metal types independently.

> It looks really cheap

It is pretty much the same cost as CIELAB. Just uses 2 full 3x3 matrices where CIELAB can be thought of as using matrices with a bunch of zeros in them.

Re: Oklab: A perceptual color space for image processing

#66

This is some great work. The notable point here is that the work is done by a Computer Graphics Programmer using Open Source Free software (colorio and colour-science both for Python ) and not a Researcher using Closed Source Commercial software like Matlab.

I'm not sure why all these are capitalized as some sort of formal titles, but matlab is very rarely used in computer graphics. Computer graphics is mostly fairly simple math that needs to scale well and not have edge cases. Some papers have had their algorithms in matlab but it is the exception in research and basically never used in any sort of production sense, because you would just have to port it to C++ to use i…

computer graphics and color science communities are fairly distinct, although obviously there is some overlap.

Re: Oklab: A perceptual color space for image processing

#67

Earlier quoted context omitted.

FWIW, researchers I know use C++, Python, Linux and many open-source tools.

For colour science though?

Sure. I think you are seeing a path dependence thing - more so in the past, but still there are engineering departments that are very matlab oriented, and others that are not. So depending who you work with, you'll see a ton of it or little.

This is a bit like the python/R dichotomy in data science.

Re: Oklab: A perceptual color space for image processing

#68
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...

Re: Oklab: A perceptual color space for image processing

#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.

Re: Oklab: A perceptual color space for image processing

#70

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.
Post reply on HN