Repository navigation
Color blind-friendly default color cycle #9460
Description
The default tab10 qualitative colormap is not color blind friendly, at least with my form of color blindness; I have difficulty telling the second and third colors apart. It would be nice to have a new default qualitative colormap that is color blind friendly, since it's the most commonly used. As Matplotlib 2 is finding increased adoption, I'm often coming across plots that I have difficulty reading due to the default colormap.
I find the perceptually uniform sequential colormaps quite nice, since I can actually read them. It's unfortunate that the same isn't true of the qualitative colormaps. The new Tableau 10 colormap is much better in this regard, but I'm guessing that there are intellectual property concerns that would bar including it.
Activity
jklymak commented on Oct 17, 2017
@mpetroff did you happen to see #9255? I don't know that it'll be made the default, but may help address your concerns...
WeatherGod commented on Oct 17, 2017
afvincent commented on Oct 17, 2017
I think that @mpetroff's point (please correct me if I am wrong) was more that having a not-so-great default (qualitative) color cycle makes a significant number of the plots made with Matplotlib 2 difficult to read for quite a lot of people (including him), as I guess most of the end-users simply rely on the default color cycle. From my own experience, I have to admit that even for non colorblind people, (at least) the first colors of the new default cycle are sometimes difficult to distinguish when printed out in grayscale...
Unfortunately, I guess that changing again the default color cycle is not a plausible option before Matplotlib 3 :/ and that the best we can currently do is indeed to provide nice colorblind-friendly color cycles (like #9255), possibly with more “advertising” about them in the relevant part of the documentation.
Edit: English...
WeatherGod commented on Oct 17, 2017
mpetroff commented on Oct 17, 2017
@jklymak I had only searched the issues, not the pull requests, so thanks for pointing that out.
@WeatherGod Yes, I meant color cycle. I wrote colormap, since I was looking at the set of colors on the colormap documentation page.
As @afvincent surmised, my main point is that the default color cycle should be color blind-friendly, since many people will just use the default.
dstansby commented on Oct 19, 2017
I think this is really important and should be fixed as soon as possible. Are there major problems with changing the default color cycle? Would it be possible to do this in 2.2?
WeatherGod commented on Oct 19, 2017
mpetroff commented on Oct 19, 2017
I have some ideas for creating a tool for creating color blind-friendly color cycles and quantitative colormaps. The gist of it is to create a color picker that enforces a minimum perceptual distance between the different selected colors both for normal color vision and various degrees of color blindness, such as by using the color blindness simulation and color similarity tools in Colorspacious (these thresholds would be adjustable). I'll see if I can get a prototype together in the next month or so.
lrq3000 commented on Jan 29, 2018
@mpetroff This would be awesome! Any news on this?
mpetroff commented on Jan 30, 2018
I made significant progress on this in October, building a web app with D3.js and some custom WebGL shaders, but haven't had time to work on it more recently.
Most of the functionality is there, but I still need to add the color blindness simulation to the color distance constraint (it's currently only enforcing a minimum standard perceptual distance). I hope to have time to work on this again in the next month or two.
mpetroff commented on Mar 29, 2018
I found time to work on the color cycle picker the last few weeks and was able to mostly finish it. I pushed the code to mpetroff/color-cycle-picker and have a hosted copy at https://colorcyclepicker.mpetroff.net/. Feedback is definitely welcome (but should probably be left on the repository's issue tracker instead of here to avoid clutter).
The picker enforces a minimum perceptual distance between colors in CAM02-UCS and a minimum lightness distance. It also simulates protanomaly, deuteranomaly, and tritanomaly and enforces the minimum perceptual distance for the simulated colors, treating each CVD type separately. Colors are picked from a CAM02-UCS gamut. The minimum distances and the severity of the CVD simulation are all configurable.
PaulEcoffet commented on Jul 25, 2018
Have you heard of I want hue ? It generates color map in a similar fashion as your color picker but with clustering instead. Might be interesting to have a look at their source code.
mpetroff commented on Aug 3, 2018
It takes a very different approach, and, unfortunately, I find many of the color sets it generates to be hard to distinguish, even when using the "colorblind friendly" preset. The clustering approach is an interesting concept, though.
31 remaining items
timhoffm commented on Jul 13, 2021
"Cn" is the n-th color of the current/active color/property cycle. There's only one at a time.
Naming: There was an inconclusive discussion on naming colors in #12009 (comment) and following posts.
ahrendsen commented on Feb 1, 2022
So the question is what to name the cycle rather than each of the individual colors? I think there's an obvious choice, and I don't know if you've avoided mentioning it to prevent seeming narcissistic, but I don't think there's any shame.
petroff-colorblind10
If you want to avoid attaching your name to it, maybe something like:
perceptual-colorblind10
These keep with the existing tableau-colorblind10 naming format which I've just discovered is actually a styling and not a color cycle.
My own personal preference would be to stick to the six color cycle. When restricting yourself to keeping things colorblind friendly, I think you quickly come across colors that aren't immediately distinguishable. I see that happening with colors 4, 9, and 10 in the 10 color cycle. I advocate that if your plot has more than 6 different lines that you need to distinguish on it, it's time to reconsider which pieces of data you want your readers to focus on.
timhoffm commented on Feb 2, 2022
IMHO (and that's the point in #12009 (comment)) the main issue is that we do not have a good API for named color sequences. We only have ListedColormap, from which one can extract the colors again and use as plt.rcParams['axes.prop_cycle'] = plt.cycler(color=plt.colormaps['Pastel1'].colors). However, ListedColormap carries all the notion of colormapping which is rather confusing because we only need a sequence of colors. I'd rather not add more ListedColormaps.
mpetroff commented on Feb 2, 2022
My tendency would be to avoid using "colorblind" in the name, since there are people who will inevitably decide to treat it as a special case to use only if they are going to show a plot to a colleague who they know is colorblind (and only if they remember). But maybe, I'm being too cynical. Regardless, in an ideal world things would be accessible by default, so there wouldn't be a need to specifically name it as such.
@ahrendsen If I'm understanding your comment about colors 4, 9, and 10 in the ten-color cycle, you find those three color fairly similar. If that is the case, the metric used to choose the order worked as designed, since if only eight items are plotted, the colors are all easily distinguished. It's only when nine or ten items are plotted that it becomes more difficult.
timhoffm commented on Feb 3, 2022
we are very conservative in changing the default visual aspects of a plot because people are used to how their plots look. Even changing colors can be a source of irritation. For now this would be opt-in. Visual changes are only done in major releases.
jklymak commented on Feb 3, 2022
Do we need one? Where would we use it, and why would it be superior to a bare list of colors?
mpetroff commented on Feb 3, 2022
I know. Since we don't live in an ideal world, I'm just being optimistic that the defaults will eventually be accessible.
timhoffm commented on Feb 3, 2022
Color sequences themselves can be simple lists of colors. What we don't have it is a central space to store them by name. IMHO we want something like plt.color_sequences[name] --> list of color values.
Use cases are e.g.
or
for y, color in zip(datasets, plt.color_sequences['Pastel1']): plt.plot(x, y, color=color) plt.text(x[0], y[0], 'some description', color=color)In the simplest case color_sequences could be a dict. We just need to define and document it. In practice however, I'd create a similar structures as the ColormapRegistry so that 1) you cannot delete or overwrite builtin color sequences and 2) it returns a copy to prevent accidental in-place modifications of registered sequences.
That's all fairly trivial and I can put together a PR later. But IMHO it's valuable to make that concept explicit.
timhoffm commented on Feb 3, 2022
See #22387 for the proposed ColorSequenceRegistry.
github-actions commented on Oct 9, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!