Repository navigation
Add .colorblindfriendly attribute to colormaps, docs, _repr_png_ #17893
Description
STORY: Users can determine whether a colormap is designed to be compatible with colorblindness.
Tasks:
- Add e.g
.colorblindfriendlyattributes to colormaps - Display attribute in the docs
- Display attribute in the new colormap
_repr_png_
Add _repr_png_ for figures with no configured IPython backend #17891
Reacted by Bradley Dice
Activity
story645 commentedon Jul 12, 2020
I think this would be good, but I think this attribute should be a list of which types of colorblindness the colormap is appropriate for.
timhoffm commentedon Jul 12, 2020
Is this something we need to add (public) API for? seems like mostly a documentation topic.
westurner commentedon Jul 12, 2020
Is there a convention for including such metadata in the docstrings? An
._underscoredattr would also serve to remind folks that you can just pick a colormap that's colorblind-friendly and not have to worry about ittacaswell commentedon Jul 12, 2020
The benefit of adding the colorblind information to the objects is now you can get the list of colormaps and filter to only see the kinds you want. Rather adding a
.colorblindfriendlyattribute I would rather add a.metadata(or similary) attribute which is a dictionary with keys like{'perceptually_uniform', 'colorblindsafe', 'type'}(where type is "{ramp, diverging, catagorical, ...}".I think the first check in the initial list should be
From a technical side I do not see any challenges here. Where I see the challenge is making sure the schema is complete and flexible enough to cover all the colormaps out there in the wild (but still locked down enough to be useful!) and getting consensus on that schema.
I think we want input from at least @kthyng (cmocean), @story645 , @jbednar (colorcet), @jiffyclub (palettable), @stefanv, @njsmith and @jamienunez (who are the people off the top of my head that maintain widely used packages of additional colormaps or do research in this space, I am definitely leaving people out).
I am in theory 👍 💯 on this, but it needs a champion to do the cat-herding, including making sure we have collected enough cats and making sure there is not an obvious prior art we can just use.
jiffyclub commentedon Jul 12, 2020
Definitely sounds like a good idea to me to have this metadata to help with colormap discovery and selection. Where it was available I'd try to make it available in palettable as well.
westurner commentedon Jul 12, 2020
The schema.org accessibility properties do not yet seem to have anything relevant to colorblindness. Standardization may be worth the delay. Is there any existing JSONLD metadata in Matplotlib?
tacaswell commentedon Jul 13, 2020
Not that I am aware of.
stefanv commentedon Jul 13, 2020
@njsmith Started working on a format for sharing colormaps, but I don't think that work was ultimately finalized: https://github.com/matplotlib/viscm/blob/master/viscm/examples/sample_linear.jscm
jbednar commentedon Jul 13, 2020
I agree this information would be great to make available in a computer-accessible form.
HoloViews already provides a little database with information like this for Matplotlib colormaps and others, as documented in our colormaps guide and accessed using a command
list_cmaps(provider, category, source, bg, ...). For instance, to list all the perceptually uniform monotonic (sequential) colormaps from Matplotlib suitable for contrast against a light background, you can do:We use this database in graphical apps so that a
colormapselector displays only the colormaps suitable for the current situation, not all of the hundreds of colormaps available. It would be great to be able to further filter it by maps suitable for protanopes, deuteranopes, tritanopes, etc., which for us would just be a matter of listing that information as another field to filter on.I'm not certain it was a good idea, but we already use partial-string matching, so that
list_cmaps(category="Uniform Sequential")returns a subset of the records that matchlist_cmaps(category="Sequential"). Similarly here in our code we could have colormaps declared asColorblindfriendly Protanopia,Colorblindfriendly Deuteranopia, etc., so that one couldlist_cmaps(category="Colorblindfriendly")to get all matching maps, orlist_cmaps(category="Colorblindfriendly Deuteranopia")to get only those suitable for Deuteranopes.mpetroff commentedon Jul 15, 2020
There should also be some sort of definition by which a colormap is determined to be colorblind-friendly, so we avoid the situation where something is labeled as colorblind-friendly but isn't (e.g., Seaborn's "colorblind" palette or the claims made in the blog post that introduced the
turbocolormap). I made an attempt at quantifying this in a blog post I wrote in response to the claims made aboutturbo, which arose because an inaccurate colorblindness simulation tool was used to evaluate it (the prevalence of highly-inaccurate simulation tools, including ones with no scientific provenance, is quite problematic). However, my attempt is still far from a binary classifier about colorblind-friendliness, and I'm sure that there are better approaches. In general, perceptually-uniform colormaps are usually reasonable, but rainbow colormaps are not.While it seems the existing consensus is just to use "-optia" labels, I want to make explicit that this is the correct approach and that "-omaly" labels should not be used, since they cover a wide-spectrum of deficiencies (see, e.g., the comment on the Chromium issue tracker for why "-omaly" simulations were removed).
jbednar commentedon Jul 15, 2020
I think that's a great idea -- specify a well-founded tool that can be run to provide a metric for how friendly a given colormap is to a particular type of colorblindness, then agree on a threshold (guided by rejecting false positives like Seaborn "colorblind" and turbo), so that we can binarily classify each map. I agree that focusing on the more extreme -opia variants is sufficient and less confusing than trying to cover all the -omaly variants.
Such a classifier could be hosted at https://github.com/pyviz , as it's independent of Matplotlib specifically.
brobr commentedon Jul 16, 2020
Just to comment on this great idea: There are tools out there, e.g. https://asada.website/webCVS/index.html, which allow to test colors; it demonstrates the various aspects of colorblindness. You can test your own images there.
It could also be relevant for when printing a color-figure to grey-scale; as discussed in the PythonDataScienceHandbook (p257-258). For example, the cubehelix map seems to behave better for both coloblindness and grey-printing than the red/blue scheme:
https://github.com/jakevdp/PythonDataScienceHandbook
mpetroff commentedon Jul 16, 2020
@brobr You have to be careful with the tools "out there," since many are unfortunately quite inaccurate. The website you linked to implements Brettel et al. (1997), which only simulates "-opia" deficiencies with reasonable accuracy; however, the website still has a "simulation ratio" slider for simulating "-omaly" deficiencies, even though the underlying algorithm is not designed for that. Thus, the website is only accurate in certain configurations, with no clear indication from the UI as to which configurations those are. However, it's still much, much better than the top Google search result for "color blindness simulator," which is horribly inaccurate and uses a simulation function with little to no scientific basis. It uses the "Human-Computer Interaction Resource Network simulation function," which I haven't been able to determine a provenance for, but it is horribly inaccurate (for protanopia, reds should appear darker than they would otherwise appear, but it makes them lighter). The "colorjack.com matrices," which are currently used by the Firefox dev tools, are similarly inaccurate and were apparently just made up by their author. The more recent Machado et al. (2009) paper produces similar results to Brettel et al. (1997) for "-opia" deficiencies while also providing a method of simulating "-omaly" deficiencies and is, best I can tell, the current state-of-the-art; this is conveniently implemented by the Colorspacious library.
Yes, grayscale-readability is also an important consideration. Fortunately, grayscale-readable colormaps are generally decent for colorblind individuals as well, since they primarily encode the input variable in lightness, which is fairly invariant to color perception, instead of hue.
westurner commentedon Jul 16, 2020
1 remaining item
jbednar commentedon Jul 16, 2020
Right, I think it would be up to us to write a script using colorspacious that accepts a colormap and returns metric values for each simulated condition that we can use to make a binary classification of suitability of that map for that condition. Personally, I have a very strong background in "normal" human color perception from my academic vision research, but only cursory knowledge of colorblindness, so I'd nominate someone else (@mpetroff ?) to be the one to lead there.
jklymak commentedon Jul 16, 2020
I'm concerned with the idea that Matplotlib should definitively say a colormap is colorblind-friendly or perceptually uniform, or anything else. I like how https://github.com/matplotlib/viscm/blob/master/viscm/examples/sample_linear.jscm expresses these designations as "usage_hints". If someone doesn't like the "hint" they can ignore it, but I'd be concerned about something definitive like
{'colorblind-safe':True}.jbednar commentedon Jul 16, 2020
viscm does call them hints, but also calls them safe, which is a binary label (safe vs. unsafe):
Personally, I think that there is a huge disparity between the number of people who use Matplotlib colormaps and the number who understand (or even want to understand) details of perceptual uniformity and the various models of colorblindness and visual perception. I think we do a disservice to users to simply dump a whole bunch of colormaps on people without guidance or advice. No one has to listen to the advice, but I think some broad-stroke binary labels like "perceptually uniform" (according to some criterion) and "colorblind safe" (according to some criterion) can help ordinary users do the right thing in most cases, making the world a much better place than if we adopt a more hands-off approach and leave it to the users to make calls about which maps are suitable.
jklymak commentedon Jul 16, 2020
In my opinion, certifying fitness for a given purpose of a colormap (or anything else) is outside of matplotlib's scope. If there is a given standard we can point to that would be great, but I don't think core Matplotlib should maintain that standard.
OTOH I'm 💯 on the idea of a standard, and would be fine if matplotlib colormaps wanted to reference that standard. I'm also quite excited by the idea of more metadata on the colormap object, and I think a serializable colormap exchange format would be fabulous.
jbednar commentedon Jul 16, 2020
I think Tom is proposing that we (this group, which is larger than just Matplotlib) define such a standard, and I'm proposing that it can live in the neutral (and as yet largely unused) territory https://github.com/pyviz, as a resource for all Python plotting libraries to refer to and to contribute to.
That said, Matplotlib is the de facto plotting standard for Python, and so it's very important what guidance Matplotlib provides to users. E.g. Matplotlib focusing on perceptually uniform colormaps starting a few years ago has been a major step forward for Python viz, making vastly more people aware of the issues involved than was true previously. So I think Matplotlib has a special role here, but this topic is of course larger than Matplotlib specifically.
tacaswell commentedon Jul 17, 2020
I agree with @jbednar .
Standardizing on a set of meta-data to attach to color maps (and an interchange format?) are A+ ideas that should be adopted more broadly than just Matplotlib and that if such a standard existed we would readily attach it to our colormap classes (and re-organize the docs to highlight "best practices"). I think that is all non-controversial :)
The thing that is missing is someone to take the lead on organizing said standard.
westurner commentedon Jul 17, 2020
Do we have a list of attributes for a schema?
C: Class
P: Property
D: Domain
R: Range
C: ColorMap/ColorPalette < https://schema.org/CreativeWork
P: name R: xsd:string
P: author R: schema:Person
kthyng commentedon Jul 20, 2020
Yes, I agree with people's comments too. Reasonable to provide some guidance here. I agree that there would need to be some actual test for colorblindness if we are going to provide the label, but that should be developed by someone with real expertise in the area.
github-actions commentedon Aug 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!
westurner commentedon Aug 9, 2023