@mpetroff did you happen to see #9255? I don't know that it'll be made the default, but may help address your concerns...

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...

@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.

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?

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.

@mpetroff This would be awesome! Any news on this?

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.

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.

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.

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.

It would be great to have this as a default color cycle, but in any case, would it be possible to implement this similar to the "C0", "C1", ... colors as "D0", "D1" etc for example? I would find that incredibly handy, as sometimes one knows about the non-colorblindness of the audience, in which case I would prefer the C0,C1,C2 colors as they are easier to separate, whereas in other situations D0,D1,D2 would be better

An initiative to introduce the new tableau colors as (non-default) colormap/-cycler is in #12009. It was however not well received.

Just to be clear, folks know we have an rcParam to set the default cycle in your matplotlib.rc or via a style? axes.prop_cycle can be set to any cycle you want. i.e. like in #9255,

# Tableau colorblind 10 palette
 axes.prop_cycle: cycler('color', ['006BA4', 'FF800E', 'ABABAB', '595959', '5F9ED1', 'C85200', '898989', 'A2C8EC', 'FFBC79', 'CFCFCF'])

I've been working on another approach to addressing this issue by combining randomly generated color sets that have an enforced minimum perceptual distance including color vision deficiency simulation with an online survey to collect data on what's aesthetically pleasing:

https://colorcyclesurvey.mpetroff.net/

Obviously, this is only useful if I'm able to collect enough survey responses. Details of the technique are included in a pair of blog posts.

I'm not seeing an action item here so closing, but feel free to reopen if I'm incorrect...

The action item would be to change the default color cycle to something that's more colorblind friendly. Unfortunately, it's not yet clear what the better default would be.

OK, fair enough - re-opening and de-milestoning

Woudl seaborn's colorblind variation of the default palette work?

It's similar to the current color cycle, making it a relatively small change.

Speaking for my own colorblindness, the second half of the Seaborn palette is not. I find colors 3, 6, and 8 quite similar to each other and also find colors 7 and 10 to be similar to each other as well.

Thanks, that's unfortunate.

Starting with the blue at 162deg and going clockwise, to match the indexing of the "deep" palette shown above the figure (1-indexed).