FYI the notebook isn't working for me in IPython 2.2.0 I agree with Michael's sentiment that from a marketing perspective, a matplotlib-only colormap is advantageous to maintain a consistent brand. Will these colormaps also be used for non-imshow/colormesh/pcolormesh data, as in for line colors as well? I think that's a great idea! It'll make the black and white versions easier to understand since the changing colors will monotonically increase/decrease in darkness rather than randomly changing. RE: Nathaniel - I'm not as much of a fan of changing line styles in addition to colors, but that's my personal preference for plotting lines specifically. When plotting scatters, I think it does make sense, since the room to perceive a change in color is so small, that a change in shape helps too. On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom <mw...@st...> wrote: > I've made a second notebook that uses the IPython interactive machinery to > let anyone play with the parameters and explore different ways of setting > them. you can download the notebook with that here: > http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it > using IPython 3.0rc1; I'm not certain if it will work on the 2.x series; > sorry if that is the case). > > This stays with the general approach in the original notebook of using a > linear ramp for chroma, which again maybe is not what we want. But it > should let you get a better sense for the parameter space. > > As I said in the email to Olga, I think (a) I would advocate fairly > strongly that matplotlib should design a custom colormap as its default, > and (b) I think this approach (a cubehelix-like map in Hcl space) is a > principled way of doing so (though maybe not optimal). But both of those > points are independent of whether you end up going with the particular > parameters that I used to generate the original proposal -- I have my own > domain on which to impose my personal aesthetic preferences, and I don't > need to take over matplotlib too :) > > (But I do think it's worth distinguishing the matplotlib default from the > matlab default.) > > Michael > ------------------------------------------------------------ > ------------------ > 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=190641631&iu=/ > 4140/ostg.clktrk_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
@Nathaniel I think developing the color-overhaul as a maintenance release is a decent compromise. All non-color changes get directed at the master branch and we can cherry-picked back bug-fixes as needed. The next feature release is planned for July/August, I _really_ hope sorting out the colors does not take that much longer. if we start to Paint a Bike Shed that just needs to be shut down. I am not sure how I feel about a _default_ non-trivial style-cycle. +1 on providing the machinery and rcparams to do it and agnostic which branch it goes on. @Olga I think there are two separate issues, the default color map used by ScalarMappable and the default color cycle that `ax.plot` and company use. I think both should be up for discussion and do not _need_ to use the same colors. Tom On Wed Feb 18 2015 at 7:43:31 PM Olga Botvinnik <obo...@uc...> wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. > > Will these colormaps also be used for non-imshow/colormesh/pcolormesh > data, as in for line colors as well? I think that's a great idea! It'll > make the black and white versions easier to understand since the changing > colors will monotonically increase/decrease in darkness rather than > randomly changing. > > RE: Nathaniel - I'm not as much of a fan of changing line styles in > addition to colors, but that's my personal preference for plotting lines > specifically. When plotting scatters, I think it does make sense, since the > room to perceive a change in color is so small, that a change in shape > helps too. > > On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom <mw...@st...> > wrote: > >> I've made a second notebook that uses the IPython interactive machinery >> to let anyone play with the parameters and explore different ways of >> setting them. you can download the notebook with that here: >> http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it >> using IPython 3.0rc1; I'm not certain if it will work on the 2.x series; >> sorry if that is the case). >> >> This stays with the general approach in the original notebook of using a >> linear ramp for chroma, which again maybe is not what we want. But it >> should let you get a better sense for the parameter space. >> >> As I said in the email to Olga, I think (a) I would advocate fairly >> strongly that matplotlib should design a custom colormap as its default, >> and (b) I think this approach (a cubehelix-like map in Hcl space) is a >> principled way of doing so (though maybe not optimal). But both of those >> points are independent of whether you end up going with the particular >> parameters that I used to generate the original proposal -- I have my own >> domain on which to impose my personal aesthetic preferences, and I don't >> need to take over matplotlib too :) >> >> (But I do think it's worth distinguishing the matplotlib default from the >> matlab default.) >> >> Michael >> > ------------------------------------------------------------ >> ------------------ >> 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=190641631&iu=/ >> 4140/ostg.clktrk_______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > ------------------------------------------------------------ > ------------------ > 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=190641631&iu=/ > 4140/ostg.clktrk_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Wed, Feb 18, 2015 at 4:42 PM, Olga Botvinnik <obo...@uc...> wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > Oops, sorry. > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. > Just to be clear, I wasn't suggesting *matplotlib only* in the (legal) sense that parula is matlab only, just that it should be identifiably "the matplotlib colormap". > Will these colormaps also be used for non-imshow/colormesh/pcolormesh > data, as in for line colors as well? I think that's a great idea! It'll > make the black and white versions easier to understand since the changing > colors will monotonically increase/decrease in darkness rather than > randomly changing. > I wasn't really thinking the plt.plot line cycle, more about plt.scatter, plt.contour, etc. and other places that accept a cmap argument but don't draw an "image-like" plot. Though, having a default colormap that can be used when you want to encode a quantitative value in the color of lines, e.g. the figures here: http://www.machenslab.org/publications/machens_etal_2010.pdf, would be good too. That's somewhere you often find people using jet.
On 2015年02月18日 2:42 PM, Olga Botvinnik wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. Provided we can find a good colormap for that purpose; right now the only sequential proposals are gray, YlGnBu, and Michael's new HCL. Aesthetically, I find boring old YlGnBu the most pleasant of this small set. I agree with Michael's point that its yellow end might be lighter than optimum. To me, the HCL map is not downright ugly, but its definitely not appealing, either. My guess is that the prevalence of blues and greens in nature makes it easier for many people, myself included, to react favorably to large expanses of those colors for long periods of time. > > Will these colormaps also be used for non-imshow/colormesh/pcolormesh > data, as in for line colors as well? I think that's a great idea! It'll > make the black and white versions easier to understand since the > changing colors will monotonically increase/decrease in darkness rather > than randomly changing. I think that the line color cycling default should not match the default colormap at all; instead, it is in the "categorical" category, with visual ordering being secondary. All colors should be highly visible and distinguishable whether on a computer screen, paper, or projected by a poor projector in an overly lit room. Eric