Create a palette variation for red-green colorblind users

[flavorjones]

I'm red-green colorblind (protanopia), and I found it impossible to differentiate between "cyan" and "base0" -- i.e., in Emacs, the color used for strings was indistinguishable from normal text.

I found that increasing the blue aspect of "cyan" helped greatly -- see my fork's commit here: https://github.com/flavorjones/emacs-color-theme-solarized/commit/7c7b5aaab96765ffb269c7d98bd1e275baa353ef

But in general, I'm wondering if there's been any effort made to create variations of solarized for various colorblind users. I'd certainly be willing to assist by representing protanopes.

The science of colorblindness is relatively well understood (see http://dankaminsky.com/2010/12/15/dankam/ for the calculations behind the DanKam), so I'd love to see what can be done to make solarized more useful for colorblind people.

[cqr]

I am also red-green colorblind. I support this patch.

SOLIDARITY!

[altercation]

Colorblind users of the world unite! I support your cause! Rise up!

I did actually test Solarized in colorblindness simulators during development. See below for details on that. For the moment, I just checked the actual color values in your commit and I see that you are changing:

-    (cyan    "#2aa198" "#259185" "#00afaf")
+    (cyan    "#2aa198" "#2591aa" "#00afaf")

That central RGB value is not from Solarized at all. I don't know what it is exactly without going through the emacs port in more detail, but I'm assuming it's there to address specific term fallback conditions where the actual Solarized colors aren't available. (@sellout, can you clarify?).

That being said, if you are using that value you aren't using the actual Solarized colorscheme. The first value (#2aa198) is the correct value. This value should be available via emacs guis. In terminal mode, you'll have to set your terminal up with the solarized colors first.

---

Regarding my general strategy on colorblindness support during development, ultimately I settled on the following approach:

1. Ensure that the CIELAB Lightness value contrast between ground and foreground colors is always enough to be clear in all colorblindness variants (this is one of the major benefits of using CIELAB Lightness as a key design value)
2. Syntax files (in vim and I'm sure in most other editors) are all over the map in how they end up using the base syntax color groups to actually highlight code. It's very difficult to ensure that there are no color 'collisions' (i.e. different hues subject to colorblindness in adjacent positions) for all syntaxes, so I stopped pursuing this directly.
3. I have considered creating an option like "g:solarized_colorblindness" which could take different values for different types of colorblindness and remap colors accordingly. I.e. If red/green, maybe remap red to an alternate hue (still within the Solarzed palette of course). I'd need vim testers here. I'm assuming the same could be done in emacs or any reasonable capable text editor that supports cleverness in the colorscheme file.
4. I am very hesitant to actually change hues as they have been very carefully selected and refined over months and each has a tightly coupled relationship with the others and has been tested in a variety of conditions. Item 3 above is really a preferred solution as it would allow retention of the current hues (of course the key issue on your commit is noted above, specifically that the RGB value in play isn't a Solarized value at all).

[sellout]

That second value is used by the GUI, not terms. Emacs, as I understand it, doesn't support sRGB. When I first created the port, I used your hex values, but got complaints that it didn't match the colors those same users saw in Vim, EG, this image from sellout/emacs-color-theme-solarized#5. That issue covers the topic pretty well, I think, but to summarize, that second column is a machine-dependent translation to "generic" RGB that was generally agreed to be closer to the colors users saw in Vim.

I would love to get rid of it and use the sRGB colors directly, but I'm not sure that's possible.

[altercation]

@sellout, I'll test here too. The problem I see with machine specific colors is that it will be different on every machine (i.e. there is an implied colorspace transform implemented by using the second value). So either emacs gui is using some crazy ass colorspace that you are essentially remapping back to srgb by sending it the second column value, or something else is going on.

[flavorjones]

Wow, thanks for the thoughtful responses, @altercation and @sellout.

@sellout - it's worth mentioning that color.el contains a bunch of utility functions, including color-srgb-to-xyz which appears to do the conversion from sRGB into CIE XYZ space, which might or might not be useful for the emacs port. Although to be honest, the conversation here about the functions in that file just plain confuses me, which tells me that I'm probably in over my metaphorical colorspace head.

[altercation]

@flavorjones, I checked into the other threads on @sellout 's repo on this issue and I think he has the best bandaid approach on this for now with the second column of hex values, but I'm trying to see if I can get a slightly more accurate "baked in" color transform.

That being said, color.el is interesting. Why in the hell it uses CIE xyz and not CIELAB I do not understand. I could generate tristimulus values from LAB for use via color.el.

[flavorjones]

@altercation - Ah! color.el also has CIELAB transformation methods, too.

[altercation]

Interesting. That might be an alternate approach. For what it's worth, I'm testing the Generic Space values in the current theme and when tested against a direct sRGB output they appear to be correct. I'll do more testing but looks good so far, at least as a stopgap.

[Parakleta]

I have made a variant that works for my particular colourblindness and makes each of the colours distinct, although it probably destroys the aim of the original solarized palette.

[sellout]

So, Emacs on OS X has now had sRGB support for two years, and my Solarized for Emacs has been using it for all of that time. If there are still issues with indistinguishable colors for colorblind users, I would be happy to hear about them on the sellout/emacs-color-theme-solarized repo. However, that should really only be for issues where you see the Emacs colors differ from the Vim ones.

If the problem also exists on Vim, @altercation sounds like he is happy to address it, and that’ll trickle down to Emacs afterward.

But it seems like perhaps this particular issue is resolved with the no-longer-new support of sRGB in Emacs.