Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Implements the Okabe-Ito accessible colormap.#30821

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
brooks-code wants to merge10 commits intomatplotlib:main
base:main
Choose a base branch
Loading
frombrooks-code:add_okabe_ito_accessible_colormap

Conversation

@brooks-code
Copy link

PR summary

This pull request proposes an implementation of the Okabe-Ito qualitative colormap introduced by this research paper:

Okabe, M. & Ito, K. (2002). Color Universal Design (CUD)
How to make figures and presentations that are friendly to Colorblind people.https://jfly.uni-koeln.de/color/

The paper recommends"a set of colors that is unambiguous both to colorblinds and non-colorblinds".

This colormap is supported by later research and is already implemented in software like ggplot2. It is also important in the book "Fundamentals of Data Visualization" by Claus Wilke.

  • Why is this change necessary?
    Everyone does not see the same way. More than 20% of the time, a plot will be reviewed by at least one individual with a color vision deficiency.

  • What problem does it solve?
    It bridges the gap between users with different visual abilities by providing a colormap that is visually appealing and accessible toall groups.

  • What is the reasoning for this implementation?
    Allow for greater inclusivity using a scientifically backed color palette.

accessible
Source

PR checklist

brooks-code reacted with rocket emoji
@github-actionsgithub-actionsbot added topic: color/color & colormaps Documentation: examplesfiles in galleries/examples Documentation: user guidefiles in galleries/users_explain or doc/users labelsDec 7, 2025
@timhoffm
Copy link
Member

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?

@brooks-code
Copy link
Author

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 thedefault 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 beingreliably 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 (Petroffhas not been designed with color print-friendliness in mindSee 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 atTable 2.

timhoffm reacted with thumbs up emoji

@story645
Copy link
Member

What's the licensing on Okabe-Ito?

Copy link
Member

@story645story645 left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

If we take this PR then we have to decide on a name - we don't want to crown one sequence as "accessible". Also looks like there are stray commits that I think a rebase would fix.

ETA: I'm a +1 on accepting this, so long as the license is fine - it's a published sequence that's been implemented in other visualization tools & addresses accessibility constraints the other sequences don't.

timhoffm reacted with thumbs up emoji
Copy link
Author

@brooks-codebrooks-code left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Changed sequence name from 'Accessible' to 'Okabe_Ito', feel free to suggest any other better name.

brooks-codeand others added4 commitsDecember 10, 2025 14:26
Fixed commentCo-authored-by: hannah <story645@gmail.com>
story645 suggestion.Co-authored-by: hannah <story645@gmail.com>
Co-authored-by: hannah <story645@gmail.com>
@timhoffm
Copy link
Member

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 lowercasehttps://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?

brooks-code reacted with thumbs up emoji

@brooks-code
Copy link
Author

brooks-code commentedDec 13, 2025
edited
Loading

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

story645 reacted with thumbs up emoji

@story645
Copy link
Member

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

brooks-code reacted with thumbs up emoji

@brooks-code
Copy link
Author

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

Copy link
Member

@timhoffmtimhoffm left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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.

@brooks-code
Copy link
Author

brooks-code commentedDec 14, 2025
edited
Loading

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 (seehere) for a discussion of this issue). Accordingly, by default, this function uses a darker more "amber" color for "yellow" ("#F5C710").

Fromthe R documentation.

The trade-off with amber-variant is that it becomes less distinguishable from the orange (#e69f00) that is also present in the sequence 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:
comparison_colors_okabe ito

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

@timhoffm
Copy link
Member

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.

@brooks-code
Copy link
Author

In this case I haven't found a best-of-all worlds proven solution. We could have a darker orange (a bit brownish then), but then we take the risk of messing with the red/green and lose points on CVD-friendliness.

  1. Original sequence: better overall distinguishability, but yellow performs poorly against whites.
  2. Amber-variant: amber reads better against whites, orange vs. amber can be a bit confusing (but still distinguishable).
    Both sequences are accessible in terms of CVD-friendliness.

A global preview:
okabe_variants

@brooks-code
Copy link
Author

brooks-code commentedDec 15, 2025
edited
Loading

I’d give the amber variant a +1, imho, it looks more versatile: better against white and thus more screen/print-friendly, while still remaining CVD accessible.

@story645
Copy link
Member

Do we wanna split the difference and have 'okabe_ito' and 'okabe_ito_amber'?

@brooks-code
Copy link
Author

@story645 Maybe that makes the palette a bit redundant somehow but that's the option the devs agreed upon in R/ggplot2.

Accordingly, by default, this function uses a darker more "amber" color for "yellow" ("#F5C710"). This color is the "yellow" color used in base R >4.0'sdefault color palette. The palettes "full" and "black_first" use this darker yellow color. For the original yellow color suggested by Okabe and Ito ("#F0E442"), use palettes "full_original" or "black_first_original".

story645 reacted with thumbs up emoji

@timhoffm
Copy link
Member

It depends, on a number of aspects, including "how far apart" are the orange and yellow elements, is it lines, text, areas, etc.

imageimage

In these pictures, I'm +0.5 on the original as it is easier to discern from orange. Text readability is worse, but that's not the primary use of color sequences. We also have to realize it's the fifth color in the cycle and many plots use less thatn that, so maybe the topic is not too relevant.

I'd go with the original one named 'okabe_ito'. This would still leave us the option to add 'okabe_ito_amber' later.

brooks-code reacted with thumbs up emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@story645story645Awaiting requested review from story645

@timhoffmtimhoffmAwaiting requested review from timhoffm

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

accessibilityDocumentation: examplesfiles in galleries/examplesDocumentation: user guidefiles in galleries/users_explain or doc/userstopic: color/color & colormaps

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@brooks-code@timhoffm@story645

[8]ページ先頭

©2009-2025 Movatter.jp