Hacker News new | ask | show | jobs
by areyousure 638 days ago
Do operating system accessibility controls help you distinguish the colors? For example, both Windows 10/11 and MacOS have "color filters". https://support.microsoft.com/en-us/ windows/use-color-filters-in-windows-43893e44 b8b3-2e27-1a29-b0c15ef0e5ce https://support.apple.com/ guide/mac-help/change-display-colors-easier-onscreen mchl11ddd4b3/mac
2 comments

They can but keep in mind there are a variety of different types of color blindness and varying severity.

For me close colors on a red / green scale are difficult to differentiate. If I enable accessibility features, it will make every photo look incorrect. iOS has an excellent option to adjust the degree of color filter. Mine is set to tritanopia (blue/yellow) the only about 5 percent intensity to give me a good balance.

Kind of. All those are able to do (however it's implemented) is map some (r,g,b) -> (r,g,b). If we pick on the common example of red-green colorblindness (of which there are many types; to have something concrete to work with, let's say all cones function at "normal" intensity, but the spectrum for the red cone has been shifted near to what the green cone picks up), what kinds of mappings are you able to do?

The core problem is that many (r,g) pairs are equivalent, or nearly so. It's worth noting then that at least one of two properties holds:

(a) Your mapping is bijective. You shift things around, e.g. by swapping the green and blue channels. Any bijective technique other than the identity will, by definition, add hue distortion, making things potentially hard to interpret. You're able to, e.g., gain the ability to distinguish red and green, but that comes at the cost of not being able to distinguish red and blue, since the confused pairs still exist in the output space.

(b) Your mapping isn't injective. Many input colors map to the same output colors. One way this might be helpful is in pushing the (r,g) split toward its extremes. Maybe leave (50,50) alone, map (40,60) -> (10,90) and (30,70) -> (1,99). How much that helps varies [0], but it comes at the cost of reduced dynamic range. You traded telling colors apart for telling images with subtle variations apart. And, again, there's a hue distortion.

If we don't have any good options, what levers do you have available to play with?

1. You can (ab)use the brightness channel to carry color information. This isn't very effective since brightness steps are harder to perceive than hue steps. Most implementations will instead prefer to keep the perceptual brightness the same (for the particular colorblindness described, reds will be less bright than in normal vision and greens more bright, so you need to add a correction factor). In the abstract, I do like using the brightness channel. When out at sea I'll wear strongly tinted orange sunglasses to make detecting buoys easy (everything else is dark, but the orange buoys are bright as day).

2. You can compress the (r,g) split as described above, making reds more red and greens more green.

3. You use the blue channel somehow. This is a catch-all of sorts, but if you're keeping brightness the same and not fixing the problem with just (r,g) (and, again, people want to keep brightness the same and can't fix the problem with just (r,g) [0]), then you're mixing blue into the equation. With a goal of minimizing hue distortion, no implementation does anything as extreme as my proposal of swapping the blue and green channels. They all, instead, trade some of the (r,g) discriminative ability for extra blue. Implementation details vary. I particularly like the ones which have a sequence of tests and do a little ML to come up with a nice (r,g,b) -> (r,g,b) scheme tailored for your eyes. However it's done though, you're saturating the blue channel with extra information.

All mappings can be represented as some combination of (1,2,3), and mostly (3) in practice, which perhaps helps explain why the techniques aren't amazing in general. They all assume the goal is telling red from green, but your real goal is telling apart all the colors you need to tell apart in whichever UI you happen to be working with. The extra constraint of minimizing hue distortion helps with that, but you're still in a world where the colorblind filter helps for some UIs and doesn't for others, actively making others worse. God-forbid they have both off-red and off-blue buttons when the filter's solution was trading some red for some blue.

And you can work around that a bit by not letting the filter be quite so strong, but that comes at the cost of not being as helpful in the actual red-green case. It's one more lever that helps a bit at the OS level. You'd really like customization for the particular UI you're looking at, kind of like what user style sheets were supposed to do for the web.

[0] You don't really get "pure" colors from an LCD, so this is even less effective of a technique than it could be, and it really messes with the math (you want something kind of like an integral over relative response curves convolved with the LCD's spectrum). The particular flavor of red-green colorblindness described though, you can sometimes tell very pure reds from very pure greens.

> If we pick on the common example of red-green colorblindness (of which there are many types; to have something concrete to work with, let's say all cones function at "normal" intensity, but the spectrum for the red cone has been shifted near to what the green cone picks up), what kinds of mappings are you able to do?

You could animate it by changing the mapping over time; then colorblind people would see that two identical colors are changing differently.

You could also try replacing colors with a pattern but it wouldn't work that well.