[HN Gopher] Issues with Color Spaces and Perceptual Brightness
___________________________________________________________________
Issues with Color Spaces and Perceptual Brightness
Author : todsacerdoti
Score : 106 points
Date : 2025-01-17 07:01 UTC (16 hours ago)
(HTM) web link (johnaustin.io)
(TXT) w3m dump (johnaustin.io)
| kevingadd wrote:
| 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.
| kookamamie wrote:
| See Oklab colorspace for an attempt at fairer perceptual
| brightness: https://bottosson.github.io/posts/oklab/
| kpil wrote:
| This page was interresting and demonstrates some problems with
| CIELabls hue perception:
| https://raphlinus.github.io/color/2021/01/18/oklab-critique....
| refulgentis wrote:
| 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.
| andrewla wrote:
| Oklab is mentioned in the article as also being flawed in this
| sense.
| weinzierl wrote:
| _" 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.
| cccbbbaaa wrote:
| That, or the more recent darktable UCS:
| https://eng.aurelienpierre.com/2022/02/color-saturation-cont...
| balou23 wrote:
| 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
| weinzierl wrote:
| 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.
| mattdesl wrote:
| 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.
| cccbbbaaa wrote:
| This colorspace is used internally by the color balance RGB
| module of Darktable (and Ansel).
| Aeolun wrote:
| LCH works pretty well for perceptually uniform. At least in my
| experience.
| drewcon wrote:
| Came here to say that. Seems to solve the problem around
| uniformity and also chroma is basically "gray" he's talking
| about.
| qwertox wrote:
| 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 Stefan van der Walt_
| https://www.youtube.com/watch?v=xAoljeRJ3lU
| smidgeon wrote:
| Available in several formats at
| http://seaviewsensing.com/pub/cpt-city/mpl/
| Animats wrote:
| 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
| myfonj wrote:
| 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?
| fredgrott wrote:
| this is why Google's HCT color space has both a Tone as
| adjustment and device environment as a color adjust.
| refulgentis wrote:
| 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)
| RealStickman_ wrote:
| For a slightly humorous explaination and exploration of color
| spaces, I highly recommend this video.
|
| https://youtu.be/fv-wlo8yVhk
| mxfh wrote:
| 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
| runsonrum wrote:
| I found this article to be very helpful
|
| https://keithjgrant.com/posts/2023/04/its-time-to-learn-oklc...
| seanwilson wrote:
| > 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).
| mark-r wrote:
| I've found the WCAG contrast ratio to be almost worthless.
| Unless you have a legal requirement to use it, I'd stay away.
| seanwilson wrote:
| 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.
| _kb wrote:
| 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
| jorvi wrote:
| 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 :).
| atorodius wrote:
| 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
| Sesse__ wrote:
| Try the Mel or Bark scales :-)
| mark-r wrote:
| 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.
| morsch wrote:
| 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.
| jorvi wrote:
| Sonos has a loudness toggle! Sadly its much too aggressive
| and applies even at 50% volume.
| mrob wrote:
| 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.
| lieks wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| 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
| ttoinou wrote:
| 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
|
| Its the other way around : we perceive logarithmically _so_ we
| created the logarithmic decibel scale
| andrewla wrote:
| 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.
| mark-r wrote:
| 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.
| WithinReason wrote:
| This is the main reason why CIELAB was developed
| vanderZwan wrote:
| So as a guy with protanomaly, the biggest shock for me when I got
| my colorlite glasses1 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.
|
| 1 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...
| ChrisMarshallNY wrote:
| 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/
| bnetd wrote:
| 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.
| viggity wrote:
| 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
| TinkersW wrote:
| That is the standard approach, but if you try to tonemap using
| it, you will quickly realize it really really sucks.
| PaulHoule wrote:
| 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.
| vanderZwan wrote:
| ... 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
| leoc wrote:
| 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.
| refulgentis wrote:
| 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.
| andrewla wrote:
| 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.
| hatthew wrote:
| precise results would depend heavily on screen calibration
| andrewla wrote:
| 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.
| hatthew wrote:
| 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.
| boulos wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-17 23:01 UTC)