Oklab: A perceptual color space for image processing
bottosson.github.io
Oklab: A perceptual color space for image processing
1–10 of 94 posts
Re: Oklab: A perceptual color space for image processing
#2This 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.
Re: Oklab: A perceptual color space for image processing
#3This 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 colour chart and the Luo-Rigg data!
This should also be mandatory reading for people not so serious about computer colour, because heads up: If you do any kind of arithmetic on RGB bytes, you've screwed up much more than you think you have! It's one of the most common examples of the Dunning–Kruger effect.
Need a nice gradient of colours to represent something graphically, such as low-medium-high values? Go to this page first.
Need to blur a background picture? Go to this page first.
Resizing images? Read this first.
Making colour schemes for a web page theme? This page first.
Adding a "colour picker" control? Definitely read this first.
Re: Oklab: A perceptual color space for image processing
#4> 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.
Re: Oklab: A perceptual color space for image processing
#5I 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.
Re: Oklab: A perceptual color space for image processing
#6This 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:
Re: Oklab: A perceptual color space for image processing
#7Apropos D65, just a reminder that 65K is perceptually blue tinted. Just as D50 is red tinted. 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 problematic, you might consider rendering using a non-standard 58K whitepoint. Just saw someone burned by this the other day, with a "supposed to be white with a localized tint" object (the Sun), which D65 then confused.
Re: Oklab: A perceptual color space for image processing
#8This 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've been trying to get into this area of study.. what did you read to know all this stuff?
Re: Oklab: A perceptual color space for image processing
#9Apropos D65, just a reminder that 65K is perceptually blue tinted. Just as D50 is red tinted. 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 problematic, you might consider rendering using a non-standard 58K whitepoint. Just saw someone burned by this the other day, with a "supposed to be white with a localized tint" object (the…
> 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 "supposed to be white with a localized tint" object (the Sun), which D65 then confused.
Isn’t that what the ICC’s relative rendering intent is supposed to take care of, if I understand what you mean?
Re: Oklab: A perceptual color space for image processing
#10This 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 and the camera shutter. That's why CV needs a color space where colors remain close to each other, no matter the frame brightness.