(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=41507563

简而言之,给定的文本讨论了为患有某些形式色盲(特别是红绿色盲)的个体调整数字彩色显示的挑战。 作者提出了三种主要的调整方法: 1.利用亮度通道来传达颜色信息,由于难以区分亮度与色调的差异,因此可能效果不佳。 2. 压缩红绿光谱,增强红色和绿色色调,同时降低整体动态范围。 3. 将蓝色通道与方法 1 或 2 结合使用,以提供额外的颜色信息,而不会产生过多的色调失真。 文中还提到,这些方法的组合在实际应用中最常使用。 虽然这些方法为某些接口提供了帮助,但它们可能会降低其他接口的性能。 此外,文本还提出了适应性,允许用户针对特定场景定制界面,例如佩戴橙色有色眼镜以提高海上能见度。 最终,作者得出的结论是,理想的解决方案将涉及基于个人需求和所使用的特定界面的用户特定定制。

相关文章

原文






























































































































































































































































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.















































































































联系我们 contact @ memedata.com