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 :).
A 3dB increase is a doubling of a power quantity, but you need 6dB to double a root-power quantity (formerly called a field quantity). Sound pressure is root-power quantity:
Consider a loudspeaker playing a constant-frequency sine wave. Sound pressure is proportional to the excursion of the cone. To increase sound pressure, the excursion has to increase, and because frequency is fixed the cone will have to move faster. If it's covering twice the distance in the same time interval it has to move twice as fast. Kinetic energy is proportional to the square of velocity, so doubling the sound pressure requires four times the power, and doubling the power only gets you sqrt(2) times the sound pressure.
Human loudness perception generally requires greater than 6dB increase to sound twice as loud. This depends on both frequency and absolute level as you mentioned, with about 10dB increase needed to double perceived loudness at 1kHz and moderate level.
> Stevens' power law is an empirical relationship in psychophysics between an increased intensity or strength in a physical stimulus and the perceived magnitude increase in the sensation created by the stimulus
I've played around with this a little bit while trying to engineer the "perceptually loudest ringtone sound". I thought a square wave or pulsed white noise would work well, but I found that the bell-like "telephone ring" seemed perceptually louder.
I now have to read up on the Harman curve because I'm curious about this and it has a direct practical application.
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
My 202x LG sound bar has 8 sound modes ("Music with MERIDIAN", or "Get in the zone during your game with vivid sound effects", ...). Who knows what any of them do, but presumably one of them corresponds to the loudness button.
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 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.
This looks nothing like actual Cyberpunk 2077. It looks actually realistic - unlike the base game itself where, just like in about every other game since "Physically Based Rendering" became a thing, everything looks like it's made of painted plastic.
Per the video description, this version of C2077 is modded up to its eyeballs. I'm very interested in those mods now, because it's the first time I ever saw someone managed to get materials in a game look somewhat realistic.
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?
hey, I made that! I wish the environment adjust was used, but it's not. Tone in HCT is ""just"" the L* criticized in the article (opinionated comment on that here, TL;DR: talking about color sucks, lightness/brightness are loaded terms, and the article is off-base due to it https://news.ycombinator.com/item?id=42738943)
I was looking out for a mention of Oklab and didn't see it while reading. If anyone else is wondering, you have to click on the [1] footnote to see it.
A significant mis-step - naively eschewed actual lightness, the thing that dictates what people actually perceive, because people outside the field regularly conflate brightness and lightness.
"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.
Although the article is intimidating, the implementation appears pretty simple and flexible. Has anyone tried using this either in the Darktable app or in their own libraries? I might like to try porting it to JS to compare it for web based color picker GUIs.
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.
Not sure. The article is long and I only skimmed it, but what stood out to me were the following paragraphs:
"After trying to fix Oklab for a dozen of hours, it appeared that the numerical issues it raises are grounded into design constraints we don’t need for the current task. And so do most of the other perceptual spaces.
[..]
So we could fit an Lch model directly from Munsell hue-value-chroma dataset, without going through LMS space and without even tilting the lightness plane. Doing so, we will not try to model the physiology of vision, but approach the problem as a geometric space distortion where the Munsell hues and the saturations (as a ratio of chromas / values) can be predicted by a 1D mapping from the hues, chromas and lightnesses of forming the principal dimensions of the model.
This model will need to be invertible. We will try to fit brightness data to derivate correlates of perceptual brightness accounting for the Helmholtz-Kohlrausch effect. Using the brightness and saturation correlates, we will rewrite our image saturation algorithm in terms of perceptually-even operators."
They obviously took a lot from Oklab but it seems to me they did more than just modifying it to reduce the residual error. But again, I just skimmed and I can be completly wrong.
There's the strange phenomenon that people like to say "bright red" as much as it is an oxymoron.
#ff0000 is, in terms of brightness, pretty dark compared to #ffffff yet there is a way it seems to "pop out" psychology. It is unusual for something red to really be the brightest color in a natural scene unless the red is something self-luminous like an LED in a dark night.
> It is unusual for something red to really be the brightest color in a natural scene unless the red is something self-luminous like an LED in a dark night.
Right. Just the extremely common cases where humans deliberately use red lights because of the fact that they are perceived as being very bright. Stop lights, brake lights, tail lights, emergency vehicle lights, aviation obstruction lighting, emergency flairs, emergency exit lights, etc.
> Just the extremely common cases where humans deliberately use red lights because of the fact that they are perceived as being very bright. Stop lights, brake lights, tail lights, emergency vehicle lights, aviation obstruction lighting, emergency flairs, emergency exit lights, etc.
Green lights have the greatest perceived brightness, and green is used as the go signal in traffic lights for that reason. Red light (1) has a common cultural association with danger stemming from its association with natural fire, (2) has the least impact on night vision because of the relative insensitivity of human eyes to it; the former is the reason it is used or things like stop/warning/etc. lights that might be used in any background lighting conditions, and the latter is the reason it is used for emergency guide lighting and signage that are likely to be used in dark background conditions especially where people would be at substantial likelihood of transitioning the illuminated area to an even darker environment (such as one without or with nonfunctional emergency lighting.)
... have you ever checked if you might be colorblind? Speaking as someone with protanomaly who used to think "bright red" wasn't bright until he got functioning colorblindness-correcting lenses (as I explained in a comment elsewhere in this discussion).
> There's the strange phenomenon that people like to say "bright red" as much as it is an oxymoron.
It's not. Reds can be dark or bright relative to other reds, and "bright red" -- as you would expect from the way that adjectives work -- refers to a red that is bright relative to other reds.
So as a guy with protanomaly, the biggest shock for me when I got my colorlite glasses¹ was that the traffic signs with bright blue and dark red colors suddenly looked dark(er) blue with very bright red. I asked my (normal vision) friends how they experienced those traffic signs and it was the latter. The lenses corrected for that.
It was actually quite shocking how much more sense most color choices in art and design made to me, which was a much bigger reason for me to keep wearing the glasses than being able to distinguish red, green and brown better than before. The world just looks "more balanced" color-wise with them.
While it was very obvious early on in my life that I experienced most green, red and brown colors as ambiguously the same (I did not know peanut butter was not green until my early thirties), the fact that there also were differences in perceptual brightness had stayed completely under the radar.
¹ And yes, these lenses do work, at least for me. They're not as scummy as enchroma or other colorblind-"correcting" lenses, for starters you can only buy them after trying them out in person with an optometrist, who tests which type of correction you need at which strength. Ironically their website is a broken mess that looks untrustworthy[0]. And their list of scientific publications doesn't even show up on Google Scholar, so they probably have near-zero citations[1]. But the lenses work great for me.)
If 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:
It seems that this would be well-suited to a simple online test -- show a square with one color and a square inside of that with a different color, and ask the user whether the inner square is brighter (or too close to call). Aggregate this across users and assess the fit to the CEILAB or other color spaces. It seems like you could get almost all hn users to take a stab at this for a bit before they get sick of it.
True, but the results would likely still be useful, particularly when choosing colors for web sites which will be displayed on the same distribution of screens.
I think this is likely, but easily validated -- you'd probably see a couple of clusters or some latent variables, but the raw data would still likely be useful for getting average response characteristics.
Amy Gooch's Color2Gray and various follow-on work has better coverage of the OP's actual goal:
> evaluate relative brightnesses between art assets, and improve overall game readability
The method in Color2Gray is trying to enhance salience, but the paper does a good job of comparing the problems (including red / blue examples in particular).
Like other commenters, I think oklab would look better than CIELAB on the example given in the OP. https://bottosson.github.io/posts/oklab/#comparison-with-oth... and the Munsell data below it show it to be a lot more uniform than either CIELAB or CIELUV.
> 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:
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).
Why worthless? I'm not saying it's perfect, but isn't it a better-than-nothing guide? If you've got good eyesight, it's not always intuitive which colors have good contrast. If WCAG says the contrast is bad, it's probably bad (but there are known exceptions where it gets it wrong).
https://www.inclusivecolors.com/ includes the APCA contrast measurement which is meant to be more accurate than WCAG, if you want to experiment with how it compares.
WCAG and APCA mostly agree on what has good vs bad contrast for dark on light color pairs with some exceptions. For light on dark colors though, WCAG isn't accurate and ACPA is much stricter in what's allowed.
There's another problem nobody ever talks about. The way our RGB monitors work, some colors will be more intense than others at the same brightness. A red or blue patch will only emit half as many photons as a magenta patch, because magenta includes both red and blue. The non-linear response of the eye helps here, but not completely.
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.
This is something photographers and filmmakers had to (and sometimes still have to) deal with when shooting on black-and-white film, surely? (Though maybe B&W film sometimes has noticeably different responses to light at different visible frequencies, which might happen to counter this, or to heighten it?) There’s a long history of using colour lens filters with B&W film.
Yeah, B/W film was definitely not all that accurate. It was a common practice to use weird makeup, lighting, colors, in order to create a B/W film image that looked correct (see chocolate used for blood).
So in those cases, filmmakers had to counteract the limitations of the b/w transformations in the actual sets.
Hmm, the red definitely looks more vivid to me, but I'm not sure I would say it's lighter. In an HSL-type colorspace I would say it has more S, but not more L.
This is actually a very good point that nobody else has commented on. The very definition of lightness is somewhat ambiguous. I would argue that vividness itself is a unique axis, separate from saturation.
But which axis you care about is very context specific.
For some adjacent work in the analogue domain, there's a exceptional set of paintings here that play with the fuzziness of this perception: https://www.pstruycken.nl/EnS20.html
I'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.
Not even wrong, in the Pauli sense: lightness is not brightness, red is dark in terms of lightness, you're looking for chroma to be represented in lightness which would make it not-lightness. Anything different would result in color blind people seeing it differently.
I once had an app that used a lot of colored bars with text labels on top of them, and I wanted a programmatic way to determine if a color should use black text or white text because R+G+B over some threshold was not working. I stumbled upon the YIQ color space where Y is the perceived luminance. Under 128 got a white text, over 128 got black text. Worked like a charm.
> 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.
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 :).
A 3dB increase is a doubling of a power quantity, but you need 6dB to double a root-power quantity (formerly called a field quantity). Sound pressure is root-power quantity:
https://en.wikipedia.org/wiki/Power,_root-power,_and_field_q...
Consider a loudspeaker playing a constant-frequency sine wave. Sound pressure is proportional to the excursion of the cone. To increase sound pressure, the excursion has to increase, and because frequency is fixed the cone will have to move faster. If it's covering twice the distance in the same time interval it has to move twice as fast. Kinetic energy is proportional to the square of velocity, so doubling the sound pressure requires four times the power, and doubling the power only gets you sqrt(2) times the sound pressure.
Human loudness perception generally requires greater than 6dB increase to sound twice as loud. This depends on both frequency and absolute level as you mentioned, with about 10dB increase needed to double perceived loudness at 1kHz and moderate level.
I have a theory that this generalizes to some extent.
Pitch perception is also logarithmic; an octave in music is a 2x ratio.
Memory is sort of logarithmic; you'd say a thing happened 1-2 days ago or 1-2 years ago, but not 340-341 days ago.
Same with age; someone being 10 years older than you is a much bigger deal when you're 10 than when you're 80.
It does! https://en.wikipedia.org/wiki/Stevens's_power_law
> Stevens' power law is an empirical relationship in psychophysics between an increased intensity or strength in a physical stimulus and the perceived magnitude increase in the sensation created by the stimulus
I've played around with this a little bit while trying to engineer the "perceptually loudest ringtone sound". I thought a square wave or pulsed white noise would work well, but I found that the bell-like "telephone ring" seemed perceptually louder.
I now have to read up on the Harman curve because I'm curious about this and it has a direct practical application.
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
Try the Mel or Bark scales :-)
I can't remember the last time I saw a "loudness" button. My receiver from 1980 had one but my receiver from 2000 does not.
My 202x LG sound bar has 8 sound modes ("Music with MERIDIAN", or "Get in the zone during your game with vivid sound effects", ...). Who knows what any of them do, but presumably one of them corresponds to the loudness button.
Sonos has a loudness toggle! Sadly its much too aggressive and applies even at 50% volume.
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 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.
[1] https://en.wikipedia.org/wiki/Tone_mapping
[2] https://youtu.be/aWlX793ACUY?t=145
> Here's a clip from Cyberpunk 2077.[2]
This looks nothing like actual Cyberpunk 2077. It looks actually realistic - unlike the base game itself where, just like in about every other game since "Physically Based Rendering" became a thing, everything looks like it's made of painted plastic.
Per the video description, this version of C2077 is modded up to its eyeballs. I'm very interested in those mods now, because it's the first time I ever saw someone managed to get materials in a game look somewhat realistic.
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?
> 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.
Or, very famously 20 years ago in Half-Life 2: Lost Coast, which was released as a tech demo for HDR rendering.
this is why Google's HCT color space has both a Tone as adjustment and device environment as a color adjust.
hey, I made that! I wish the environment adjust was used, but it's not. Tone in HCT is ""just"" the L* criticized in the article (opinionated comment on that here, TL;DR: talking about color sucks, lightness/brightness are loaded terms, and the article is off-base due to it https://news.ycombinator.com/item?id=42738943)
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....
Oklab is mentioned in the article as also being flawed in this sense.
I was looking out for a mention of Oklab and didn't see it while reading. If anyone else is wondering, you have to click on the [1] footnote to see it.
A significant mis-step - naively eschewed actual lightness, the thing that dictates what people actually perceive, because people outside the field regularly conflate brightness and lightness.
"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...
Although the article is intimidating, the implementation appears pretty simple and flexible. Has anyone tried using this either in the Darktable app or in their own libraries? I might like to try porting it to JS to compare it for web based color picker GUIs.
This colorspace is used internally by the color balance RGB module of Darktable (and Ansel).
This is an incredible reference, thanks.
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
Not sure. The article is long and I only skimmed it, but what stood out to me were the following paragraphs:
"After trying to fix Oklab for a dozen of hours, it appeared that the numerical issues it raises are grounded into design constraints we don’t need for the current task. And so do most of the other perceptual spaces.
[..]
So we could fit an Lch model directly from Munsell hue-value-chroma dataset, without going through LMS space and without even tilting the lightness plane. Doing so, we will not try to model the physiology of vision, but approach the problem as a geometric space distortion where the Munsell hues and the saturations (as a ratio of chromas / values) can be predicted by a 1D mapping from the hues, chromas and lightnesses of forming the principal dimensions of the model.
This model will need to be invertible. We will try to fit brightness data to derivate correlates of perceptual brightness accounting for the Helmholtz-Kohlrausch effect. Using the brightness and saturation correlates, we will rewrite our image saturation algorithm in terms of perceptually-even operators."
They obviously took a lot from Oklab but it seems to me they did more than just modifying it to reduce the residual error. But again, I just skimmed and I can be completly wrong.
There's the strange phenomenon that people like to say "bright red" as much as it is an oxymoron.
#ff0000 is, in terms of brightness, pretty dark compared to #ffffff yet there is a way it seems to "pop out" psychology. It is unusual for something red to really be the brightest color in a natural scene unless the red is something self-luminous like an LED in a dark night.
> It is unusual for something red to really be the brightest color in a natural scene unless the red is something self-luminous like an LED in a dark night.
Right. Just the extremely common cases where humans deliberately use red lights because of the fact that they are perceived as being very bright. Stop lights, brake lights, tail lights, emergency vehicle lights, aviation obstruction lighting, emergency flairs, emergency exit lights, etc.
> Just the extremely common cases where humans deliberately use red lights because of the fact that they are perceived as being very bright. Stop lights, brake lights, tail lights, emergency vehicle lights, aviation obstruction lighting, emergency flairs, emergency exit lights, etc.
Green lights have the greatest perceived brightness, and green is used as the go signal in traffic lights for that reason. Red light (1) has a common cultural association with danger stemming from its association with natural fire, (2) has the least impact on night vision because of the relative insensitivity of human eyes to it; the former is the reason it is used or things like stop/warning/etc. lights that might be used in any background lighting conditions, and the latter is the reason it is used for emergency guide lighting and signage that are likely to be used in dark background conditions especially where people would be at substantial likelihood of transitioning the illuminated area to an even darker environment (such as one without or with nonfunctional emergency lighting.)
... have you ever checked if you might be colorblind? Speaking as someone with protanomaly who used to think "bright red" wasn't bright until he got functioning colorblindness-correcting lenses (as I explained in a comment elsewhere in this discussion).
[0] https://news.ycombinator.com/item?id=42737700
> There's the strange phenomenon that people like to say "bright red" as much as it is an oxymoron.
It's not. Reds can be dark or bright relative to other reds, and "bright red" -- as you would expect from the way that adjectives work -- refers to a red that is bright relative to other reds.
So as a guy with protanomaly, the biggest shock for me when I got my colorlite glasses¹ was that the traffic signs with bright blue and dark red colors suddenly looked dark(er) blue with very bright red. I asked my (normal vision) friends how they experienced those traffic signs and it was the latter. The lenses corrected for that.
It was actually quite shocking how much more sense most color choices in art and design made to me, which was a much bigger reason for me to keep wearing the glasses than being able to distinguish red, green and brown better than before. The world just looks "more balanced" color-wise with them.
While it was very obvious early on in my life that I experienced most green, red and brown colors as ambiguously the same (I did not know peanut butter was not green until my early thirties), the fact that there also were differences in perceptual brightness had stayed completely under the radar.
¹ And yes, these lenses do work, at least for me. They're not as scummy as enchroma or other colorblind-"correcting" lenses, for starters you can only buy them after trying them out in person with an optometrist, who tests which type of correction you need at which strength. Ironically their website is a broken mess that looks untrustworthy[0]. And their list of scientific publications doesn't even show up on Google Scholar, so they probably have near-zero citations[1]. But the lenses work great for me.)
[0] https://www.colorlitelens.com/
[1] https://www.colorlitelens.com/color-blindness-correction-inf...
One of the most useful tools in my arsenal, is Sim Daltonism[0]. It's Apple-only, but I'm sure there are similar tools for Windows and Android.
[0] https://michelf.ca/projects/sim-daltonism/
If 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
Available in several formats at http://seaviewsensing.com/pub/cpt-city/mpl/
It seems that this would be well-suited to a simple online test -- show a square with one color and a square inside of that with a different color, and ask the user whether the inner square is brighter (or too close to call). Aggregate this across users and assess the fit to the CEILAB or other color spaces. It seems like you could get almost all hn users to take a stab at this for a bit before they get sick of it.
precise results would depend heavily on screen calibration
True, but the results would likely still be useful, particularly when choosing colors for web sites which will be displayed on the same distribution of screens.
I think this is likely, but easily validated -- you'd probably see a couple of clusters or some latent variables, but the raw data would still likely be useful for getting average response characteristics.
Amy Gooch's Color2Gray and various follow-on work has better coverage of the OP's actual goal:
> evaluate relative brightnesses between art assets, and improve overall game readability
The method in Color2Gray is trying to enhance salience, but the paper does a good job of comparing the problems (including red / blue examples in particular).
Like other commenters, I think oklab would look better than CIELAB on the example given in the OP. https://bottosson.github.io/posts/oklab/#comparison-with-oth... and the Munsell data below it show it to be a lot more uniform than either CIELAB or CIELUV.
> 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).
I've found the WCAG contrast ratio to be almost worthless. Unless you have a legal requirement to use it, I'd stay away.
Why worthless? I'm not saying it's perfect, but isn't it a better-than-nothing guide? If you've got good eyesight, it's not always intuitive which colors have good contrast. If WCAG says the contrast is bad, it's probably bad (but there are known exceptions where it gets it wrong).
https://www.inclusivecolors.com/ includes the APCA contrast measurement which is meant to be more accurate than WCAG, if you want to experiment with how it compares.
WCAG and APCA mostly agree on what has good vs bad contrast for dark on light color pairs with some exceptions. For light on dark colors though, WCAG isn't accurate and ACPA is much stricter in what's allowed.
There's another problem nobody ever talks about. The way our RGB monitors work, some colors will be more intense than others at the same brightness. A red or blue patch will only emit half as many photons as a magenta patch, because magenta includes both red and blue. The non-linear response of the eye helps here, but not completely.
This is the main reason why CIELAB was developed
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
This is something photographers and filmmakers had to (and sometimes still have to) deal with when shooting on black-and-white film, surely? (Though maybe B&W film sometimes has noticeably different responses to light at different visible frequencies, which might happen to counter this, or to heighten it?) There’s a long history of using colour lens filters with B&W film.
Yeah, B/W film was definitely not all that accurate. It was a common practice to use weird makeup, lighting, colors, in order to create a B/W film image that looked correct (see chocolate used for blood).
So in those cases, filmmakers had to counteract the limitations of the b/w transformations in the actual sets.
For a slightly humorous explaination and exploration of color spaces, I highly recommend this video.
https://youtu.be/fv-wlo8yVhk
Hmm, the red definitely looks more vivid to me, but I'm not sure I would say it's lighter. In an HSL-type colorspace I would say it has more S, but not more L.
This is actually a very good point that nobody else has commented on. The very definition of lightness is somewhat ambiguous. I would argue that vividness itself is a unique axis, separate from saturation.
But which axis you care about is very context specific.
LCH works pretty well for perceptually uniform. At least in my experience.
Came here to say that. Seems to solve the problem around uniformity and also chroma is basically “gray” he’s talking about.
For some adjacent work in the analogue domain, there's a exceptional set of paintings here that play with the fuzziness of this perception: https://www.pstruycken.nl/EnS20.html
I found this article to be very helpful
https://keithjgrant.com/posts/2023/04/its-time-to-learn-oklc...
I'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.
Not even wrong, in the Pauli sense: lightness is not brightness, red is dark in terms of lightness, you're looking for chroma to be represented in lightness which would make it not-lightness. Anything different would result in color blind people seeing it differently.
I once had an app that used a lot of colored bars with text labels on top of them, and I wanted a programmatic way to determine if a color should use black text or white text because R+G+B over some threshold was not working. I stumbled upon the YIQ color space where Y is the perceived luminance. Under 128 got a white text, over 128 got black text. Worked like a charm.
Y = 0.299 * R + 0.587 * G + 0.114 * B
That is the standard approach, but if you try to tonemap using it, you will quickly realize it really really sucks.
Yes, don't confuse color, chroma, and value.
> 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.
Traditional painting.
Also, to the author on the same blog, came across this: https://johnaustin.io/articles/2023/how-we-can-actually-move...
Get off the internet.