From: gary r. <gar...@gm...> - 2014-11-22 14:32:05
|
There was a talk by Kristen Thyng at scipy2014 that might be a good backgrounder for this: http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps At the end she references this site http://mycarta.wordpress.com/ of Matteo Niccoli which is full of good content. I wonder if it's worth contacting Kristen or Matteo to let them know there's a discussion going on here that they might be interested in? On 22 November 2014 at 09:53, Eric Firing <ef...@ha...> wrote: > On 2014/11/21, 4:42 PM, Nathaniel Smith wrote: > > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale <dsd...@gm...> wrote: > >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...> > wrote: > >>> > >>> Please use this thread to discuss the best choice for a new default > >>> matplotlib colormap. > >>> > >>> This follows on from a discussion on the matplotlib-devel mailing list > >>> entitled "How to move beyond JET as the default matplotlib colormap". > >> > >> > >> I remember reading a (peer-reviewed, I think) article about how "jet" > was a > >> very unfortunate choice of default. I can't find the exact article now, > but > >> I did find some other useful ones: > >> > >> > http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html > >> http://www.sandia.gov/~kmorel/documents/ColorMaps/ > >> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf > > > > Those are good articles. There's a lot of literature on the problems > > with "jet", and lots of links in the matplotlib issue [1]. For those > > trying to get up to speed quickly, MathWorks recently put together a > > nice review of the literature [2]. One particularly striking paper > > they cite studied a group of medical students and found that (a) they > > were used to/practiced at using jet, (b) when given a choice of > > colormaps they said that they preferred jet, (c) they nonetheless made > > more *medical diagnostic errors* when using jet than with better > > designed colormaps (Borkin et al, 2011). > > > > I won't suggest a specific colormap, but I do propose that whatever we > > chose satisfy the following criteria: > > > > - it should be a sequential colormap, because diverging colormaps are > > really misleading unless you know where the "center" of the data is, > > and for a default colormap we generally won't. > > > > - it should be perceptually uniform, i.e., human subjective judgements > > of how far apart nearby colors are should correspond as linearly as > > possible to the difference between the numerical values they > > represent, at least locally. There's lots of research on how to > > measure perceptual distance -- a colleague and I happen to have > > recently implemented a state-of-the-art model of this for another > > project, in case anyone wants to play with it [3], or just using > > good-old-L*a*b* is a reasonable quick-and-dirty approximation. > > > > - it should have a perceptually uniform luminance ramp, i.e. if you > > convert to greyscale it should still be uniform. This is useful both > > in practical terms (greyscale printers are still a thing!) and because > > luminance is a very strong and natural cue to magnitude. > > > > - it should also have some kind of variation in hue, because hue > > variation is a really helpful additional cue to perception, having two > > cues is better than one, and there's no reason not to do it. > > > > - the hue variation should be chosen to produce reasonable results > > even for viewers with the more common types of colorblindness. (Which > > rules out things like red-to-green.) > > > > And, for bonus points, it would be nice to choose a hue ramp that > > still works if you throw away the luminance variation, because then we > > could use the version with varying luminance for 2d plots, and the > > version with just hue variation for 3d plots. (In 3d plots you really > > want to reserve the luminance channel for lighting/shading, because > > your brain is *really* good at extracting 3d shape from luminance > > variation. If the 3d surface itself has massively varying luminance > > then this screws up the ability to see shape.) > > > > Do these seem like good requirements? > > Goals, yes, though I wouldn't put much weight on the "bonus" criterion. > I would add that it should be aesthetically pleasing, or at least > comfortable, to most people. Perfection might not be attainable, and > some tradeoffs may be required. Is anyone set up to produce test images > and/or metrics for judging existing colormaps, or newly designed ones, > on all of these criteria? > > Eric > > > > > -n > > > > [1] https://github.com/matplotlib/matplotlib/issues/875 > > [2] > http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html > > [3] https://github.com/njsmith/pycam02ucs ; install (or just run out > > of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute > > the perceptual distance between two RGB colors. It's also possible to > > use the underlying color model stuff to do things like generate colors > > with evenly spaced luminance and hues, or draw 3d plots of the shape > > of the human color space. It's pretty fun to play with :-) > > > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |