Thanks for the interest in contributing! We have a high bar on adding new colormaps: https://matplotlib.org/devdocs/devel/api_changes.html#add-or-change-colormaps-color-sequences-and-styles

In matplotlib 3.10 we added a new colorblind friendly colormap: https://matplotlib.org/devdocs/release/prev_whats_new/whats_new_3.10.0.html#accessible-colors
Why is it worth also adding Okabe-Ito?

Thank for your reply Tim. I think it’s a valuable addition that might help a lot of people. It’s quite a state-of-the-art palette for qualitative data representation. Claus Wilke uses it as the default scale in one of the leading references on data visualization: ‘Fundamentals of Data Visualization’. But why?

It is designed to address color blindness (and does so very well) while also being reliably print-friendly (something alternative colormaps are less).

On color fidelity:

• When producing figures for publication, CMYK conversion often causes hue shifts and clipping for bright or extreme color mixtures. Okabe-Ito’s hues are less prone to such conversion artifacts, so relative contrast among series is more likely to be preserved.

• Some palettes, like Petroff8 for example, use very bright (blue/orange) or unusual primaries (with very high green/blue mixes) that do not map well to CMYK and therefore lose distinguishability in print (Petroff has not been designed with color print-friendliness in mind See Additional accessibility constraints).

On contrast:

• The Okabe-Ito palette mixes darker and mid-bright colors. This provides reliable contrast on both light and dark backgrounds. In contrast (ha-ha), alternatives like Tableau colorblind schemes might appear ‘muddy’ on print because of insufficient contrast.

About other palettes:

• ColorBrewer’s Dark2 and Set1 are useful in many contexts but are less robust to CVD (let's use "color vision deficience" or CVD instead of color blindness since most actually do see colors, but differently :). It is recommended to combine them with textures or varied line styles when accessibility is required.

Note: the original Okabe-Ito yellow is quite light and can be problematic in some print workflows. It is sometimes advised to replace it with a slightly darker amber variant (for example, #f5c710, as in ggplot2).

P.-S. If you’re curious about comparative evaluations: have a look at Table 2.

What's the licensing on Okabe-Ito?

I‘m +1 on adding this. We should decide on a naming convention for color sequences.

Right now we have some color sequences starting with a capital letter, some with lowercase https://matplotlib.org/devdocs/gallery/color/color_sequences.html. We don’t yet have ones consisting of multiple words.

Options:

1. Okabe-Ito
2. Okabe_Ito
3. OkabeIto
4. okabe-ito
5. okabe_ito
6. okabeito

IMHO: 3 is not readable and errorprone due to similarity of capital I and lowercase l. 2. is a bit uncommon in that underscore+capitalization is rarely used together. 6. is too mashed together.

My favorites are 1 and 5. 5 being the standard convention for python names. 1. is a common notation in texts to name things created by multiple authors „the Okabe-Ito color sequence“. Both are partially consistent with our current naming. What do you think?

IMHO 5: okabe_ito is better and more consistent.

Using hyphens inside string dictionary keys is fine ({"okabe-ito": palette}) but it will throw syntax errors if used for variable names (the hyphen is the subtraction operator: okabe-ito reads as okabe - ito).

I'm also a vote for 5 since I think it's the most intuitive when folks are writing code.

@timhoffm @story645 Okay, I've pushed the changes to okabe_ito (option 5).

How do we stand to this comment?

Note: the original Okabe-Ito yellow is quite light and can be problematic in some print workflows. It is sometimes advised to replace it with a slightly darker amber variant (for example, #f5c710, as in ggplot2).

Do you have reference for that advice? In particular a discussion in ggplot2 or even a comment of the original authors on this would be helpful.

Yes:

The original Okabe-Ito palette's "yellow" color is "#F0E442". This color is very bright and often does not show up well on white backgrounds (see here) for a discussion of this issue). Accordingly, by default, this function uses a darker more "amber" color for "yellow" ("#F5C710").

From the R documentation.

The trade-off with amber-variant is that it becomes less distinguishable from the orange (#e69f00) but it's still OK in terms of ΔE (metric used to assess how distinguishable two colors are).

A preview that helps observe that more clearly:

If you prefer the amber variant, I will replace the original yellow:

(0.9411764705882353, 0.8941176470588236, 0.25882352941176473),  # f0e442

with the amber alternative:

(0.9607843137254902, 0.7803921568627451, 0.06274509803921569),  # f5c710

IMHO neither is really good and it depends on the display. 😢 With three tested displays, sometimes Yellow looks too faint, sometimes Amber is too close to Orange.