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

51–60 of 94 posts

Re: Oklab: A perceptual color space for image processing

#51

Post by nitrogen »

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

Quite a large number of LED fixtures flicker at line frequency, sadly, even in "luxury" buildings.

Re: Oklab: A perceptual color space for image processing

#52

Post by quag »

bjornornorn wrote: post #49
quag wrote: post #46

bjornornorn, thank you! I’m looking forward to trying it out! I’ve been using a variant of JzAzBz for the last year or so. Perceptual color spaces make image generation much easier. Can you help me understand how JzAzBz falls down?

The largest difference is that JzAzBz has been designed to model lightness perception of very bright colors and very dark colors. Depending on your use case this could either be useful or a problem, since it means that you have to be careful with the scaling of the input data to JzAzBz. E.g, if you scale a color by some value before converting to JzAzBz, the predicted hue will be different than without scaling. Oklab…

Thanks! That helps, and JzAzBz is complex when it comes to calculations.

Re: Oklab: A perceptual color space for image processing

#53

Post by [deleted] »

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/

[deleted]

Re: Oklab: A perceptual color space for image processing

#55

Post by CyberDildonics »

nitrogen wrote: post #51
CyberDildonics wrote: post #35

Earlier quoted context omitted.

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.

Quite a large number of LED fixtures flicker at line frequency, sadly, even in "luxury" buildings.

You are probably seeing early LED fixtures with terrible electronics put in luxury buildings as the hip new thing years ago. All it takes is a capacitor above 170 volts after the rectifier to smooth out the AC.

Re: Oklab: A perceptual color space for image processing

#56

Post by CyberDildonics »

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.

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

Re: Oklab: A perceptual color space for image processing

#57

Post by ska »

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/

Your OKlab vs HSV plot is useful, but left me curious what that would look like in CIE Lch just varying hue. It seems the most direct comparison to me, just workign in LCH vs your proposal and the post isn't super clear about the benefit.

Re: Oklab: A perceptual color space for image processing

#58

Post by thewebcount »

ska wrote: post #57
bjornornorn wrote: post #6

Earlier quoted context omitted.

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/

Your OKlab vs HSV plot is useful, but left me curious what that would look like in CIE L c h just varying hue. It seems the most direct comparison to me, just workign in LCH vs your proposal and the post isn't super clear about the benefit.

Actually, I'd love to see this sort of hue-only varying comparison to several other popular color spaces, including CIELAB and HLS, too.

Re: Oklab: A perceptual color space for image processing

#59

Post by smallnamespace »

alok-g wrote: post #48
raphlinus wrote: post #45

Earlier quoted context omitted.

Dithering is usually best done in a linear space; the mixing of light is modeled as a physical rather than a perceptual process. This is especially true when the pixels are small and one can imagine a low-pass filter removing the high spatial frequencies. When dithering to huge, chunky pixels that can be individually perceived, different considerations might apply.

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

Re: Oklab: A perceptual color space for image processing

#60

Post by thewebcount »

bjornornorn wrote: post #31
jacobolus wrote: post #19

Earlier quoted context omitted.

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

It was used quite a bit in video editing in the early 2000s because the video frames often came from disk or a card in that format, and you could do some fast processing tricks with it. Those days have largely passed, though.
Post reply on HN