Oklab: A perceptual color space for image processing • Hacker News Board

Re: Oklab: A perceptual color space for image processing

#31

Post by bjornornorn » Thu, Dec 24, 2020, 2:13 PM UTC

jacobolus wrote: post #19

dTal wrote: post #5

I don't understand why they don't compare it with YCbCr, which is a very similar colorspace that is much more widely used than some of the obscure ones they compare it with - notably, in JPEG.

YCrCb is roughly based on the ones mentioned (which are not at all obscure from the perspective of color science), but is supposed to be as computationally cheap as possible, and so doesn't bother doing even basic steps like undoing gamma encoding. As a result, YCrCb yields crappy results for any purpose other than image encoding. The further you get from neutral gray, the worse YCrCb gets at cleanly separating light…

Yeah, that’s pretty much why I didn’t include it.

I haven’t really seen YCrCb used except anywhere for in compression, so didn’t think of including it (an neither do most papers related to perceptual color spaces).

Re: Oklab: A perceptual color space for image processing

#32

Post by JyrkiAlakuijala » Thu, Dec 24, 2020, 2:14 PM UTC

JyrkiAlakuijala wrote: post #25

JyrkiAlakuijala wrote: post #22

This looks very similar to what I came up for pik, consequently used as main default colorspace of JPEG XL, i.e., XYB. Also butteraugli's XYB has similar ideas, but is slightly more expensive to calculate due to the biased logarithm in the compression function (instead of cubic root), but possibly scales better for HDR (say above 200 nits). JPEG XL's XYB includes more red and less green in S-receptor modeling (for th…

Another rather substantial difference is in M2 matrix of Oklab. In my experiments I don't see S-participation in colors with high spatial frequency. Because in image compression a lot of information is in high spatial frequency, one gets favorable image compression when M2 matrix is without S contribution in Luma. We use just [b b 0, a -a 0, -0.5 * c, -0.5 * c, c] in the M2 phase in JPEG XL. The two 0s there don't br…

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 sRGB approximated this by gluing a small linear ramp into the nonlinearity with if-then-logic.

Re: Oklab: A perceptual color space for image processing

#33

Post by jacobolus » Thu, Dec 24, 2020, 2:27 PM UTC

jacobolus wrote: post #30

bjornornorn wrote: post #27

Earlier quoted context omitted.

Yeah, both of those are good recommendations! I also think it is useful to focus on understanding the various experiments that have led to the different color models. The most important one is the experiments that led to CIE XYZ. Lecture notes from universities seem like one of the best sources of info about the basics. Such as this: https://www.cl.cam.ac.uk/teaching/1516/AdvGraph/02_Light_and... Other experiments th…

For those interested in the Munsell system: Landa & Fairchild 2005, "Charting Color from the Eye of the Beholder", http://markfairchild.org/PDFs/PAP21.pdf * * * Nickerson 1940 "History of the Munsell Color System and Its Scientific Application" https://doi.org/10.1364/JOSA.30.000575 1943 OSA Munsell renotations report: https://doi.org/10.1364/JOSA.33.000385 Nickerson 1976 "History of the Munsell Color System, Company…

Fun bonus: https://observablehq.com/@jrus/munsell-spin

Re: Oklab: A perceptual color space for image processing

#34

Post by ArtWomb » Thu, Dec 24, 2020, 2:38 PM UTC

bjornornorn wrote: post #6

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…

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/

Yeah, I feel like I learned more in color science in one post, than I've accumulated in a life time ;)

I'm sure you're aware that a quick and dirty method of fast image segmentation is just to compare image frames in varying color spaces. Would sRGB be the best "complement" to oklab in such a pipeline?

Also wondering aloud here if maybe you haven't stumbled upon an ideal color space for optical flow fields between pixels in moving images, in video prediction research for example? Great work!

Re: Oklab: A perceptual color space for image processing

#35

Post by CyberDildonics » Thu, Dec 24, 2020, 3:00 PM UTC

fxtentacle wrote: post #10

This is an interesting one, because they optimize for an untypical goal: "If the scale/exposure of colors are changed, the perceptual coordinates should just be scaled by a factor" For most computer vision applications, that is the opposite of what you want. When you analyze a video stream, it is quite common for frames to have different brightness due to things like aliasing between the flicker of LEDs in the room a…

Brightness is by far the biggest factor in perceptual differences and perceptual color spaces are approximations.

Also LEDs don't typically flicker unless a dimmer is on the circuit and their PCB isn't made for that. You might be thinking of florescent lights that are pulsed with a ballast.

Re: Oklab: A perceptual color space for image processing

#36

Post by JyrkiAlakuijala » Thu, Dec 24, 2020, 4:14 PM UTC

JyrkiAlakuijala wrote: post #22

This looks very similar to what I came up for pik, consequently used as main default colorspace of JPEG XL, i.e., XYB. Also butteraugli's XYB has similar ideas, but is slightly more expensive to calculate due to the biased logarithm in the compression function (instead of cubic root), but possibly scales better for HDR (say above 200 nits). JPEG XL's XYB includes more red and less green in S-receptor modeling (for th…

Ops. I believe I confused linear XYZ that enters the Oklab M1 matrix with the linear sRGB that enters the JPEG XL XYB's M1 matrix. When one converts them into the same space first, XYB and Oklab are likely even more similar with each other.

Re: Oklab: A perceptual color space for image processing

#37

Post by deltron3030 » Thu, Dec 24, 2020, 4:32 PM UTC

bjornornorn wrote: post #6

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…

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/

Great work! Just noted that the color space was already added to the culori.js library, including a cylindrical oklch variant.

Re: Oklab: A perceptual color space for image processing

#38

Post by michaelrpeskin » Thu, Dec 24, 2020, 4:36 PM UTC

Great article! I wish I would have had this a couple of years ago when I was working on improving a very old lossy image compression algorithm. I don't want to into great detail here, but there's a highly compressed image format that's designed so that it's super easy for low power (think 1990's embedded processors) to read and render. Basically the decompression is a bunch of LUTs - not just palette lookups, but also pattern lookups. The hard part is creating the LUTs which can be done on fast computers.

As the images we were trying to compress got more detail in them we had to redo the compression algorithm so that we could keep as much detail as possible. The key was to do the compression in a new color space and then undo the color space transform before we saved the LUTs.

I ended up creating an empirical color space that was the best for each tile we were compressing (think PCA), but now that I look at this, it might even do better since the perception is so consistent.

Re: Oklab: A perceptual color space for image processing

#39

Post by buildbot » Thu, Dec 24, 2020, 4:48 PM UTC

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?

Re: Oklab: A perceptual color space for image processing

#40

Post by raphlinus » Thu, Dec 24, 2020, 5:05 PM UTC

mncharity wrote: post #11

spider-mario wrote: post #9

Earlier quoted context omitted.

> Apropos D65, just a reminder that 65K is perceptually blue tinted. Just as D50 is red tinted. That really depends on the viewer’s adaptation state. > So if users will view your rendered image surrounded by an rgb-white screen, if/when the resulting small red/yellow/green/white shift is problemaic, you might consider rendering using a non-standard 58K whitepoint. Just saw someone burned by this the other day, with a…

> depends on the viewer’s adaptation state IIRC, both D65 and D50 are sufficiently extreme as to prevent full chromatic adaptation. Viewers will be aware a scene is lit "cold" or "warm"ly. > ICC’s relative rendering intent is supposed to take care of Yes. Browser support used to be poor, but I've not been following it. Firefox seems to still require user config?[1] A perhaps outdated WP article[2] suggests chrome sup…

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

I think the main 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).

I have yet to find a source on chromatic adaptation that I consider a really excellent tutorial. Certainly the Wikipedia page is cursory and abstract, which is a shame.