release strategy and the color revolution

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.

···

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 :slight_smile:

(But I do think it’s worth distinguishing the matplotlib default from the matlab default.)

Michael

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 Wed, Feb 18, 2015 at 4:42 PM, Olga Botvinnik <obotvinn@...170...> 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

···

On 2015/02/18 2:42 PM, Olga Botvinnik wrote: