I like: http://colorbrewer2.org/?type=qualitative&scheme=Dark2&n=8 or http://colorbrewer2.org/?type=qualitative&scheme=Dark2&n=7 depending on how many colors we want in the cycle (currently at 7)

Dark2 is quite good, I usually use Set2. Does it have to stay a 7 colors cycle or would it be better to increase the number?

Absolutely, we can change the number of colors to use. Also keep in mind
that slated for 1.5 (and thus 2.0), we will be able to cycle more than just
colors. We will be able to cycle linestyles and such along with colors.

On Wed, Jul 22, 2015 at 11:26 AM, Gilles Marin [email protected]
wrote:

Dark2 is quite good, I usually use Set2. Does it have to stay a 7 colors
cycle or would it be better to increase the number?

—
Reply to this email directly or view it on GitHub
#4754 (comment)
.

This could be done using the cycler plugin (or somthing in that line)? I heard about that but did not look into it. Will it be able to cycle every parameter?

Entirely minor point, but I like Seaborn's color cycle because when I plot u,g,r,i,z light curves in that order, the colors make sense 😄

In fact, I'd be perfectly happy if the community just decided to make Seaborn's default the new matplotlib style default.

Still ironing out the bugs, but this is my PR for it:
#4686

On Wed, Jul 22, 2015 at 11:32 AM, Gilles Marin [email protected]
wrote:

This could be done using the cycler plugin (or somthing in that line)? I
heard about that but did not look into it. Will it be able to cycle every
parameter?

—
Reply to this email directly or view it on GitHub
#4754 (comment)
.

This is a great idea. One related problem that I have when using seaborn is that although it changes the default colors in the color cycle it does not change the colors corresponding to the abbreviated color names (e.g. 'r', 'g', 'b', etc). Thus if you want to make a plot specifying which data should be red for example, you cannot just do "seaborn.plt.plot(mydata, 'r')", since that gives the "wrong" red color (i.e. not the one used in the default color cycle).

I think that if the default color cycle were changed, the colors that correspond to the main color abbreviatons (and perhaps their non abbreviated forms, e.g. 'red', 'blue', etc) should be changed to match the corresponding colors in the color cycle.

Ideally the colors corresponding to these "base" colors should be settable via rcParams so that styles and users can modify them as well.

Maybe this deserves its own issue? I did not create one because I've seen this mentioned in some other issues, but I have not found an issue open specifically for this.

One thing that has come up before related to this is that, if the color cycle is going to stay roughly as it is or some seaborn-like variant, it might make sense to swap red and green in the order, as blue vs red is an easier discrimination than blue vs green. This will help two-element plots.

By the way, @AngelEzquerra,

This is a great idea. One related problem that I have when using seaborn is that although it changes the default colors in the color cycle it does not change the colors corresponding to the abbreviated color names (e.g. 'r', 'g', 'b', etc). Thus if you want to make a plot specifying which data should be red for example, you cannot just do "seaborn.plt.plot(mydata, 'r')", since that gives the "wrong" red color (i.e. not the one used in the default color cycle).

As of 0.6 you can do either sns.set(palette="deep", color_codes=True) or sns.set_color_codes("deep") and this will work as you are expecting.

There is discussion of changing the mapping of r, g, b etc. However, making the mapping user configurable is a bit scary (even though I want to make switching to the xkcd color mapping from the x11 names optional).

@mwaskom the set_color_codes('deep') trick works great, and as you said it works exactly as I expected! Is there a reason why this is not the default? It makes so munch more sense (IMHO).

Regarding the reordering of the green and read in the color cycle, this touches on something that I have been also thinking about, which is how color blind friendly the new palettes and colors are. Ideally the default matplotlib styles should be both aesthetically pleasing and color blind friendly (and if possible, degrade nicely when printing in grayscale). Combining all those desirable features is possibly quite hard though!
As for @tacaswell 's comment:

There is discussion of changing the mapping of r, g, b etc. However, making the mapping user configurable is a bit scary (even though I want to make switching to the xkcd color mapping from the x11 names optional).

I have a question and a comment:

• Would the proposed changes also affect the color that corresponds to the full named colors corresponding to the r, g, b (and so on) abbreviations (i.e. 'red', 'green', etc)?
• I agree that it is perhaps a bit scary to make it possible to map, say, 'y' to some blue color. However, since that would have to be explicitly done by the user (or style maker) it does not seem that dangerous in practice...

@mwaskom the set_color_codes('deep') trick works great, and as you said it works exactly as I expected! Is there a reason why this is not the default? It makes so munch more sense (IMHO).

I agree, but when I proposed that I got a lot of pushback from the matplotlib devs, so I punted on making it default for 0.6 :)

Regarding the reordering of the green and read in the color cycle, this touches on something that I have been also thinking about, which is how color blind friendly the new palettes and colors are. Ideally the default matplotlib styles should be both aesthetically pleasing and color blind friendly (and if possible, degrade nicely when printing in grayscale). Combining all those desirable features is possibly quite hard though!

In my experience, it's quite hard to make qualitative palettes that reproduce well to grayscale, and often runs counter to your goals with a qualitative palette (i.e., you have to vary luminance, which has the effect of emphasizing certain categories over others, but without any sense of ordering that emphasis ends up being arbitrary). I think the better solution if you want to be sure that your plots will be accessible and reproduce to grayscale is to vary other attributes, such as linestyle/markershape along with color. I think cycler will help a lot here.

I like: http://colorbrewer2.org/?type=qualitative&scheme=Dark2&n=8 or http://colorbrewer2.org/?type=qualitative&scheme=Dark2&n=7 depending on how many colors we want in the cycle (currently at 7)

I find 7 colors quite limiting, and think it'd be great if more could be added. I use my own colormap with 9 colors and still occasionally run into situations where I run out of colors.

On a different note, I find seaborn's default colors nicer than ColorBrewer's Dark2 that was proposed here.

(just my 2 cents as mpl user)

I am not too fond of the ColorBrewer Dark2 for this purpose and think that seaborn or Tableau's color cycles are a better starting point.

Coming late to the party but it would be great if one could easily change the number of colors to cycle. I don't know if there is currently a way to easily make a plot with 8 lines without using the same color twice.

Regarding changing the default 'r', 'g', 'b' etc... If the devs think it's too scary to make these abbreviations user configurable, why not at least include some different 'abbreviation palettes' (chosen with rc params!) that have nice colors but don't commit crimes like mapping 'y' to blue.

I have been thinking that a "palette" feature would be nice. Kind of goes
in the similar vein of some people wanting to rework the existing
colormaps. If we have a "palette" option that impacts all things colors,
then that would be quite valuable, in my opinion. Imagine having a single
color cycle, but can change palette to "pastel" or somesuch.

On Thu, Aug 20, 2015 at 1:13 PM, Julian Irwin [email protected]
wrote:

Regarding changing the default 'r', 'g', 'b' etc... If the devs think it's
too scary to make these abbreviations user configurable, why not at least
include some different 'abbreviation palettes' (chosen with rc params!)
that have nice colors but don't commit crimes like mapping 'y' to blue.

—
Reply to this email directly or view it on GitHub
#4754 (comment)
.

+1 to a customizable palette feature!

There are two questions here:

1. changing what RGB value 'r', 'g', ... map to by default
2. Allowing the user to change that mapping

For mpl2.0 we have to address 1, but do not need to address 2.

Created new issue to track 2 #4974

Closing this as we went with category10 https://github.com/vega/vega/wiki/Scales#scale-range-literals from vega as the new default cycle.

👎 on changing the meaning of 'r' , 'g', etc.... #4383 will add many more named colors (lifted from the XKCD color survey*.

Point 2 already has it's own issue.

@tacaswell what do I do if I have 11 values ;) will it be possible to use, say category20, too?