Re: [matplotlib-devel] Better defaults all around?
I would be also quite interested in having better defaults. My list of complains are: * Easy way to get only two lines for axis (left and down, instead of four) * Better default font (Source Sans Pro / Source Code Pro for example (open source)) * Better default colormap * Better axis limit (when you draw with thick lines, they get cut) * Better icons for the toolbar (there are a lot of free icons around) * Better colors (more pastel) * Less cluttered figures * Lighter grids + All Nathaniel's suggestions Ideally, we could have a set of standard figures for each main type (plot, scatter, quiver) and tweak parameters to search for the best output. Nicolas On 22 Nov 2014, at 04:18, Benjamin Root ben.r...@ou.edu wrote: With regards to defaults for 2.0, I am actually all for breaking them for the better. What I find important is giving users an easy mechanism to use an older style, if it is important to them. The current behavior isn't buggy (for the most part) and failing to give users a way to get behavior that they found desirable would be alienating. I think this is why projects like prettyplotlib and seaborn have been so important to matplotlib. It enables those who are in the right position to judge styles to explore the possibilities easily without commiting matplotlib to any early decision and allowing it to have a level of stability that many users find attractive. At the moment, the plans for the OO interface changes should not result in any (major) API breaks, so I am not concerned about that at the moment. Let's keep focused on style related issues in this thread. Tabbed figures? Intriguing... And I really do need to review that MEP of yours... Cheers! Ben Root On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza ariza.feder...@gmail.com wrote: I like the idea of aligning a set of changes for 2.0 even if still far away. Regarding to backwards compatibility I think that indeed it is important but when changing mayor version (1.x to 2.0) becomes less important and we must take care of prioritizing evolution. Take for example the OO interface (not defined yet) this is very probable to break the current pyplot interface but still this is a change that needs to be done. In terms of defaults. I would like to see the new Navigation as default (if it gets merged) and tabbed figures (to come after navigation), having separate figures feel kind of ...old On 21 Nov 2014 21:23, Benjamin Root ben.r...@ou.edu wrote: Some of your wishes are in progress already: https://github.com/matplotlib/matplotlib/pull/3818 There is also an issue open about scaling the dashes with the line width, and you are right, the spacing for the dashes are terrible. I can definitely see the argument to making a bunch of these visual changes together. Preferably, I would like to do these changes via style sheets so that we can provide a classic stylesheet for backwards compatibility. I do actually like the autoscaling system as it exists now. The problem is that the data margins feature is applied haphazardly. The power spectra example is a good example of where we could smarten the system. As for the ticks... I think that is a very obscure edge-case. I personally prefer inward. It is good to get these grievances enumerated. I am interested in seeing where this discussion goes. Cheers! Ben Root On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith n...@pobox.com wrote: Hi all, Since we're considering the possibility of making a matplotlib 2.0 release with a better default colormap, it occurred to me that it might make sense to take this opportunity to improve other visual defaults. Defaults are important. Obviously for publication graphs you'll want to end up tweaking every detail, but (a) not everyone does but we still have to read their graphs, and (b) probably only 1% of the plots I make are for publication; the rest are quick one-offs that I make on-the-fly to help me understand my own data. For such plots it's usually not worth spending much/any time tweaking layout details, I just want something usable, quickly. And I think there's a fair amount of low-hanging improvements possible. Batching multiple visual changes like this together seems much better than spreading them out over multiple releases. It keeps the messaging super easy to understand: matplotlib 2.0 is just like 1.x, your code will still work, the only difference is that your plots will look better by default. And grouping these changes together makes it easier to provide for users who need to revert back to the old defaults -- it's easy to provide simple binary choice between before 2.0 versus after 2.0, harder to keep track of a bunch of different changes spread over multiple releases. Some particular annoyances I often run into and that might be candidates for changing: - The default method of choosing axis limits is IME really,
Re: [matplotlib-devel] How to move beyond JET as the default matplotlib colormap
Given the workload that making a release causes, is it necessary to put out a v1.4.3 at all? On a similar sounding argument, given that the removal of CXX doesn't break user APIs, and has been on master for several weeks with fewer than anticipated side-effects, do we even need a v1.5? Essentially, what is the barrier from moving straight to a v2.0 in Feb? What I'd like to avoid is this idea of we're talking about a making a major release so let's fix everything that was ever broken - my definition of a v2.0 release is really just v1.5+new default cmap. If there are other things that need fixing in a backwards incompatible way then we should discuss and plan how we are going to do that, and if there is developer appetite, there is no reason not to talk about releasing a v3.0 in 18-24 months (which is currently ~2 mpl minor release cycles). On 21 November 2014 18:56, Thomas Caswell tcasw...@gmail.com wrote: I am a bit wary of doing a 2.0 _just_ to change the color map, but when every I try to write out why, they don't sound convincing. We may end up with a 3.0 within a year or so due to the possible plotting API/pyplot work that is (hopefully) coming. If we are going to do this, I think we should do the 1.4.3 release (scheduled for Feb 1, RCs in mid January), then put one commit to change the color map on top of that, tag 2.0 and then master turns into 2.1.x (targeted for right after scipy?). There is also the thought to get the major c++ refactor work tagged and released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and 2.0 in Feb with 2.0 based off of 1.5 not 1.4. On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root ben.r...@ou.edu wrote: As a point of clarification, is this proposed 2.0 release different from the 1.5 release? On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson pelson@gmail.com wrote: Many of you will be aware of there has been an ongoing issue (#875, http://goo.gl/xLZvuL) which recommends the removal of Jet as the default colormap in matplotlib. The argument against Jet is compelling and I think that as a group who care about high quality visualisation we should be seriously discussing how matplotlib can move beyond Jet. There was recently an open letter to the climate science community http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/ asking for scientists to pledge against using rainbow like colormaps (such as Jet), and there are similar initiatives in other scientific fields, as well as there being a plethora of well researched literature on the subject. As such, it's time to agree on a solution on how matplotlib can reach the end of the rainbow. The two major hurdles, AFAICS, to replacing the three little characters which control the default colormap of matplotlib are: * We haven't had a clear (decisive) discussion about what we should replace Jet with. * There are concerns about changing the default as it would change the existing widespread behaviour. To address the first point I'll start a new mailinglist thread (entitled Matplotlib's new default colormap) where new default colormap suggestions can be made. The thread should strictly avoid +1 type comments, and generally try to stick to reference-able/demonstrable fact, rather than opinion. There *will* be a difference of opinion, however the final decision has to come down to the project lead (sorry Mike) who I know will do whatever is necessary to make the best choice for matplotlib. The second point is a reasonable response when we consider that matplotlib as a project has no *clear* statement on backwards compatibility. As a result, matplotlib is highly change averse between minor releases (to use semantic versioning terms) and therefore changing the default colormap is unpalatable in the v1.x release series. As a result I'd like to propose that the next release of matplotlib be called 2.0, with the *only* major backwards-incompatible change be the removal of Jet as the default colormap. As a project matplotlib mustn't get caught up in the trap of shying away from a major version release when the need arises, and in my opinion helping our users to avoid using a misleading colormap is a worthy cause for a v2.0. Please try to keep this thread on the how, and not on the what of the replacement default colormap, for which there is a dedicated thread. Thanks, Phil (#endrainbow) -- 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list
Re: [matplotlib-devel] Matplotlib's new default colormap
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 efir...@hawaii.edu wrote: On 2014/11/21, 4:42 PM, Nathaniel Smith wrote: On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale dsdal...@gmail.com wrote: On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson pelson@gmail.com 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.
Re: [matplotlib-devel] Matplotlib's new default colormap
The contents of that talk are also in our documentation http://matplotlib.org/users/colormaps.html Tom On Sat Nov 22 2014 at 9:33:11 AM gary ruben gary.ru...@gmail.com wrote: 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 efir...@hawaii.edu wrote: On 2014/11/21, 4:42 PM, Nathaniel Smith wrote: On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale dsdal...@gmail.com wrote: On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson pelson@gmail.com 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
[matplotlib-devel] chicken/egg (or figure/canvas) question
I thought I had this understood, but now I am confused while working on my last chapter. I know that the Figure object never directly creates its own canvas object. It starts off with a None object as a placeholder and waits for one to be given to it. However, I can only find one place where the figure object's set_canvas() method is called, and that is in the canvas's print_figure() method to restore itself as the figure's canvas after temporaraily switching to another backend for saving. I thought that the FigureManager initializes the primary canvas object, but that doesn't seem to be the case. Where is it done? Cheers! Ben Root -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] chicken/egg (or figure/canvas) question
Actually, I think I found it. It looks like each backend defines a new_figure_manager() function. Then, in backends/__init__.py, not only do the aliased FigureManager and FigureCanvas objects get imported from the appropriate module, but so does that function. It is pylab_setup() in the backends/__init__.py that creates the canvas object, it seems? I guess this is one of those remaining issues that is keeping us from fully separating pyplot from the rest of matplotlib? Cheers! Ben Root On Sat, Nov 22, 2014 at 4:30 PM, Benjamin Root ben.r...@ou.edu wrote: I thought I had this understood, but now I am confused while working on my last chapter. I know that the Figure object never directly creates its own canvas object. It starts off with a None object as a placeholder and waits for one to be given to it. However, I can only find one place where the figure object's set_canvas() method is called, and that is in the canvas's print_figure() method to restore itself as the figure's canvas after temporaraily switching to another backend for saving. I thought that the FigureManager initializes the primary canvas object, but that doesn't seem to be the case. Where is it done? Cheers! Ben Root -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] cocoaagg figure not have a navigation toolbar?
I don't have a mac to double-check, but reading through the backend_cocoaagg.py, I don't see any creation of a navigation toolbar? Is this assumption right? Thanks! Ben Root -- 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
