Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issues with color spaces and perceptual brightness

johnaustin.io

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Issues with color spaces and perceptual brightness

#11

Post by mxfh »

Desaturation methods are tricky as well. So is the image information transformation on it's way to the hardware and display hardware characteristics themselves.

Accurate color reproduction on uncalibrated consumer devices is just wishful thinking and will not be fixed in the forseeable future.

So unless you work in a color controlled and calibrated environment it's hard to make any reliable statements about perception.

I simply would not worry too much about optimizing perceptual color spaces at this point.

https://library.imaging.org/cic/articles/31/1/36

Re: Issues with color spaces and perceptual brightness

#12

Post by balou23 »

cccbbbaaa wrote: post #6
weinzierl wrote: post #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.

That, or the more recent darktable UCS: https://eng.aurelienpierre.com/2022/02/color-saturation-cont...

Someone else was mentioning Oklab color space, and I was wondering what the difference was to darktable UCS.

TL;DR: Oklab is pretty simple, but is already pretty nice as a perceptually uniform color space. Darktable UCS takes Oklab and tries to reduce the residual error.

Feel free to correct me if I got anything wrong

Re: Issues with color spaces and perceptual brightness

#13

Post by kpil »

kookamamie wrote: post #3

See Oklab colorspace for an attempt at fairer perceptual brightness: https://bottosson.github.io/posts/oklab/

This page was interresting and demonstrates some problems with CIELabls hue perception: https://raphlinus.github.io/color/2021/01/18/oklab-critique....

Re: Issues with color spaces and perceptual brightness

#15

Post by seanwilson »

> This process means that there is some error. For example, ideally, a color with L=50 looks twice as bright as a color with L=25. Except, with very strongly saturated colors like red, this isn’t actually the case in any of these color spaces.

A benefit of doing it this way is you account for color blindness and accessibility e.g. all colors at L=50 will have the same WCAG contrast ratio against all colors at L=25. This helps when finding colors with the contrast you want.

Related, I'm working on a color palette editor based around creating accessible palettes where I use the HSLuv color space which has the above property:

https://www.inclusivecolors.com/

You can try things like maxing out the saturation of each swatch to see how some some hues get more bold looking at the same lightness (the Helmholtz-Kohlrausch effect mentioned in the article I think). You can also explore examples of open source palettes (Tailwind, IBM Carbon, USWDS), where it's interesting to compare how they vary their saturation and lightness curves per swatch e.g. red-700 and green-700 in Tailwind v3 have different lightnesses but are the same in IBM Carbon (the "Contrast > View colors by luminance only" option is interesting to see this).

Re: Issues with color spaces and perceptual brightness

#16

Post by fredgrott »

Animats wrote: post #8

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

this is why Google's HCT color space has both a Tone as adjustment and device environment as a color adjust.

Re: Issues with color spaces and perceptual brightness

#18

Post by jorvi »

I've always found these "perceptual vs absolute" things about human senses very interesting.

Hearing has a few quirks too:

- When we measure sound pressure, we measure it in log (so, every 3dB is a doubling in sound pressure), but our hearing perceives this as a linear scale. If you make a linear volume slide, the upper part will seem as if it barely does anything.

- The lower the volume, the less perceivable upper and lower ranges are compared to the midrange. This is what "loudness" intends to fix, although poor implementations have made many people assume it is a V-curve button. A proper loudness implementation will lessen its impact as volume increases, completely petering off somewhere around 33% of maximum volume.

- For the most "natural" perceived sound, you don't try to get as flat a frequency response as possible but instead aim for a Harman curve.

- Bass frequencies (<110Hz, depending on who you ask) are omnidirectional, which means we cannot accurately perceive which direction the sound is coming from. Subwoofers exploit this fact, making it seem as if deep rich bass is coming from your puny soundbar and not the sub hidden behind the couch :).

Re: Issues with color spaces and perceptual brightness

#20

Post by atorodius »

jorvi wrote: post #18

I've always found these "perceptual vs absolute" things about human senses very interesting. Hearing has a few quirks too: - When we measure sound pressure, we measure it in log (so, every 3dB is a doubling in sound pressure), but our hearing perceives this as a linear scale. If you make a linear volume slide, the upper part will seem as if it barely does anything. - The lower the volume, the less perceivable upper a…

I stumbled upon this when visualizing music. It is very interesting how everything is kind of non linear, like you mention. I had to increase low frequencies and then I got stuck trying to bucket frequencies. It seems humans have different fidelity for different ranges of frequencies
Post reply on HN