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

11–20 of 94 posts

Re: Oklab: A perceptual color space for image processing

#11

Post by mncharity »

spider-mario wrote: post #9
mncharity wrote: post #7

Apropos 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…

> 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 support of V4 is OS dependent? But yes, someday this will just work.

[1] https://cameratico.com/color-management/firefox/ [2] hhttps://en.wikipedia.org/wiki/Color_management#Application_l...

Re: Oklab: A perceptual color space for image processing

#12

Post by s_gourichon »

kelsolaar wrote: post #2

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.

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

Re: Oklab: A perceptual color space for image processing

#13

Post by knolan »

The example[1] given at the start of the article is almost like the end of the first order of a Micheal Levi chart[2]. This can be used to describe thin film interference such as a layer of oil on water or a bubble’s colour.

Certainly gives it a natural look.

[1]https://bottosson.github.io/img/oklab/hue_oklab.png

[2]https://www.doitpoms.ac.uk/tlplib/liquid_crystals/images/mic...

Re: Oklab: A perceptual color space for image processing

#14

Post by reitzensteinm »

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

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.

Re: Oklab: A perceptual color space for image processing

#15

Post by coldcode »

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

As an artist who uses code a lot, this is going right into my toolset. Manipulating colors is a huge pain.

Re: Oklab: A perceptual color space for image processing

#16

Post by mkl »

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/

It's a great article, and an interesting new colour space. It would be really interesting to see a variety of image transformations done in each of these colour spaces, on a variety of images (photos in particular). E.g. resizing and blurring as jiggawatts suggests, and also things like brightness, contrast, saturation, white-balance, etc.

How big are your datasets? Would the parameters get better if they were bigger, or have they converged to some optimum?

A couple of typos I spotted: "asses", "he final".

Re: Oklab: A perceptual color space for image processing

#17

Post by mkl »

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…

I think it means the hue stays the same, since it's angle in polar coordinates, which is scale invariant. Saturation (chroma) changes though.

Re: Oklab: A perceptual color space for image processing

#18

Post by olivierduval »

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/

Hello

Really nice work!!! How does it compare with HSLuv (https://www.hsluv.org/)? It seems that both scheme try to manage the perceptual color problem...

Re: Oklab: A perceptual color space for image processing

#19

Post by jacobolus »

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 lightness from hue/chroma.

Re: Oklab: A perceptual color space for image processing

#20

Post by batty_alex »

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.

I was thinking the same thing. My guess is the author’s background is in games and that’s where this research is focused. It did give an impression that, to someone who works with color spaces, the author is operating in a different domain
Post reply on HN