On 2013/07/20 11:47 AM, Chris Beaumont wrote: > Hi, > > I thought I'd chime in on this discussion -- Adrian Price-Whelan and I > put together plotornot during the SciPy sprints. > > I wouldn't advocate for linking to plotornot from matplotlib -- the idea > is semi tongue-in-cheek, and meant to gauge to what extent there is > consensus about plot styles. It's not set up to teach about rcParams, > nor does it systematically explore all possible styles. The votes (>10K, > last I checked) are saved, and eventually Adrian or I will look over the > feedback and report back to you all. I haven't had time for that yet. I > hope the name didn't *actually* offend anyone. > > At the risk of sounding unappreciative of MPL (which I love, and rely > upon daily), I must admit I was disheartened after hearing the MPL devs > at SciPy discuss styles and defaults. I understand that you don't want > to change the default styles without a clearly better alternative. I > also understand that, to some extent, style preferences are subjective. > However, there seemed to be quite a bit of resistance to the idea that > MPL defaults should change *at all.* > > Even if you ignore the subjective component of this (which I think is a > mistake, since in my experience there is broad consensus that projects > like ggplot2, d3, tableau, and spotfire do a "better" job than MPL at > styling), there are some well-established visual principles that > matplotlib violates. Some of my biggest pet peeves are: > > 1) The default 'axes.color_cycle' values should be equally visible, with > similar luminance values. The current defaults (bgrcmyk) do not have > this property -- c and y are harder to see, and thus carry less visual > emphasis. A color table like the "Dark2" color brewer table > (http://learnr.files.wordpress.com/2009/04/colours-dark2.png, > colorbrewer2.org <http://colorbrewer2.org>) is more uniform, and > carefully designed for visibility and contrast. 'rgbcmyk' is clearly an > arbitrary choice -- why not use a smarter default? > > 2) The default 'jet' colormap for images has a lot of poor properties > (which is even mentioned on the MPL docs at > http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at > ordering changes in hue (which is bigger -- purple or yellow?), and > better at ordering changes in intensity or saturation. A colleague of > mine designed a visualization tool for doctors, and found that the > rainbow color table had a dramatic negative effect on the effectiveness > of the tool (you can watch her TED talk about this at > https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is > especially frustrating, since it *cannot* be modified via rcParams > > 3) Some of the defaults violate Tufte principles like minimizing "chart > junk." For example, the 'stepfilled' mode for hist is probably better > than the default, which draws vertical lines between every bin. Those > lines make the histogram noisier -- do they convey any extra > information? Again, this can't be tweaked via rcParams. > > Sorry for being long-winded -- I just want to make the case that this is > an important (and not *entirely* subjective) issue. If nothing else, it > would be great to see some clear statement about where the MPL devs > stand on this issue -- what criteria must be met to consider a change to > the defaults? My apologies if such a document already exists somewhere! > > Cheers, > Chris Beaumont
Chris, I appreciate the ideas, and I agree entirely that improvements are in order, so it is just a question of exactly what and how, not whether there should be changes. (For example, the default line color set often irritates me, too, because blue and green look rather similar, particularly in comparison to red, which visually overwhelms the others.) A problem with simply changing the defaults to some sort of consensus or majority opinion as to what is better is that inevitably there will be users who will be distressed when they upgrade and suddenly find that all their plots--perhaps generated automatically by their cron jobs or web apps--look very different, and perhaps don't even work well with the new defaults. Therefore we have to be somewhat conservative, and the tendency is to minimize changes that are not essential. I think that a change in the defaults will need to be staged in such a fashion that it will be as easy as possible for users to retain the old defaults if they prefer them. That leads to the idea that something like a style toolkit or cookbook, or set of examples included with mpl, might be helpful. There is never going to be one good style for all; it would be good to have examples of how to tailor things for the screen, or for paper, or for presentations, or for publications (some of which still favor black and white). The mpl examples (gallery) can be the first target for improvement; based on some experience and input, an actual change in the defaults might be announced and scheduled for some future release, with assurance that a matplotlibrc file for the old defaults will remain available for some interval. Eric ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
