Issues with color spaces and perceptual brightness
johnaustin.io
Issues with color spaces and perceptual brightness
1–10 of 67 posts
Re: Issues with color spaces and perceptual brightness
#2I've definitely struggled with this trying to do generalized stuff with colors in game visuals and UI. Using a color space like cielab or okhsl helps some but it's tough to come up with values/formulas that work just as well for red as they do for yellow, blue and purple.
Re: Issues with color spaces and perceptual brightness
#3See Oklab colorspace for an attempt at fairer perceptual brightness: https://bottosson.github.io/posts/oklab/
Re: Issues with color spaces and perceptual brightness
#4"Unfortunately, I haven’t been able to find any perceptually uniform color spaces that seem to include these transformations in the final output space. If you’re aware of one, I would love to know."
OSA-UCS takes the Helmholtz-Kohlrausch effect into consideration.
Re: Issues with color spaces and perceptual brightness
#5LCH works pretty well for perceptually uniform. At least in my experience.
Re: Issues with color spaces and perceptual brightness
#6"Unfortunately, I haven’t been able to find any perceptually uniform color spaces that seem to include these transformations in the final output space. If you’re aware of one, I would love to know." OSA-UCS takes the Helmholtz-Kohlrausch effect into consideration.
That, or the more recent darktable UCS: https://eng.aurelienpierre.com/2022/02/color-saturation-cont...
Re: Issues with color spaces and perceptual brightness
#7If this submission has put you into a mindset of wanting to know more about colormaps, here's a good video about how Matplotlib ended up having `vividris` as its default colormap:
A Better Default Colormap for Matplotlib | SciPy 2015 | Nathaniel Smith and Stéfan van der Walt https://www.youtube.com/watch?v=xAoljeRJ3lU
Re: Issues with color spaces and perceptual brightness
#8This is part of "tone mapping"[1] in high dynamic range rendering. The idea is that pixels are computed with a much larger range of values than screens can display. 16 bits per color per pixel, or even a floating point value. Then, to generate the displayed image, there's a final step where the pixel values are run through a perceptual transformation to map them into 8 bit RGB (or more, if the hardware is is available.)
This has issues. When you go from a dark space to a bright space, the eye's iris stops down. But not instantaneously. It takes a second or two. This can be simulated. Cyberpunk 2077 does this. Go from a dark place in the game to bright sunlight and, for a moment, the screen becomes blinding, then adjusts.
In the other direction, go into a dark space, and it's dark at first, then seems to lighten up after a while. Dark adaptation is slower then light adaptation.
Tone mapping is not just an intensity adjustment. It has to compensate for the color space intensity problems the OP mentions. Human eyes are not equally sensitive to the primary colors.
Some visually impaired people hate this kind of adjustment, it turns out.
Here's a clip from Cyberpunk 2077.[2] Watch what happens to screen brightness as the car goes into the tunnel and then emerges into daylight.
Re: Issues with color spaces and perceptual brightness
#9This is part of "tone mapping"[1] in high dynamic range rendering. The idea is that pixels are computed with a much larger range of values than screens can display. 16 bits per color per pixel, or even a floating point value. Then, to generate the displayed image, there's a final step where the pixel values are run through a perceptual transformation to map them into 8 bit RGB (or more, if the hardware is is availabl…
Could this be the reason I immensely dislike when webpages include blocks of inverse background/text, or generally combine light-text-on-dark with dark-text-on-light elements?
Re: Issues with color spaces and perceptual brightness
#10For a slightly humorous explaination and exploration of color spaces, I highly recommend this video.