Improve default colors and layouts

Hello there,
I created a matplotlib-wrapper, prettyplotlib and have garnered small following. I'm interested in contributing these defaults to the main matplotlib branch. The code isn't completely documented with @param and such but it should be easy to follow, and there are many examples. What is the best way to proceed?
Thanks,
Olga

At least part of this should hook up with the style sheet work (PR #2236 )

I think once we get #2236 merged (which I think will be rather soon), it would be great to have some of your settings converted to the new style file format. It does look, however, like some of the things you are doing in prettyplotlib are done in code, and can't be done in rcParams alone. It would be good to identify what those things are and perhaps propose new rcParams that could then be handled by the styling system.

Yes, I've been following #2236 . The code-based things are:

Removing top and right axis.spines
Removing xticklabels (unless log scale - then it's misleading to remove them)
For pcolormesh() and bar(), reasonable xticklabels that appear immediately below the patch they are labeling, rather than having to set xticks, and only then setting xticklabels
Different colormaps for negative-only, positive-only, and negative-and-positive-valued data. And no rainbow colormaps!!!
Legend:
- no black outline
- light grey fill
- Show only one point for a scatterplot
- legend text color to almost black (#262626)
All histograms with a white outline
All lines of a boxplot are different colors and thicknesses
Easily "annotate-able" barplots where the value of the bar is immediately above it. Or it could be annotated with some string.
- also add 0.2 whitespace padding to left of barplot (like there is padding on the right already)
- if there are negative counts, remove the bottom axes and add a line at y=0

Finally, some questions:

Right now, prettyplotlib depends on brewer2mpl but I know the Set2, etc colorbrewer colors are already in matplotlib, but I can't for the life of me figure out how to access them categorically, not as a colormap.
Is it possible for either Tony's or my's stylesheets to be the default, but allow users to use the old one as 'classic'?

I feel very strongly that changing the defaults should be treated as a major api break (like bump to 2.x) as the same code will now produce very different looking output.

Somewhat related, I don't like some of these changes (removing the spines and the ticks) and if we are going to change the default colormap we should switch from jet to cubehelix.

I agree with the major api break for any new defaults. However, I disagree
that we should be using any sort of rainbow-derived colormap, rather than a
two-color for diverging data, or single-color for simple positive or
negative data. The rainbow (even cubehelix) doesn't match human perception
of color, and especially in cases where the data is diverging and it is
important to know what is positive and what is negative, these effects are
masked by a rainbow. Source:
http://www.jwave.vt.edu/~rkriz/Projects/create_color_table/color_07.pdf

Olga Botvinnik
PhD Program in Bioinformatics and Systems Biology
Gene Yeo Laboratory | Sanford Consortium for Regenerative Medicine
University of California, San Diego
olgabotvinnik.com
blog.olgabotvinnik.com
github.com/olgabot

On Mon, Sep 30, 2013 at 2:49 PM, Thomas A Caswell
notifications@github.comwrote:

I feel very strongly that changing the defaults should be treated as a
major api break (like bump to 2.x) as the same code will now produce very
different looking output.

Somewhat related, I don't like some of these changes (removing the spines
and the ticks) and if we are going to change the default colormap we should
switch from jet to cubehelix.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2467#issuecomment-25409450
.

I've chimed in on the mailing list before, but I'm strongly in favor of changing away from jet. I think cubehelix is an improvement over jet, but it still suffers from many of the same issues (specifically, data differences are perceived differently in different data ranges; i.e. artificial banding of data).

I'd favor a sequential colormap (gray, bone, or pink), but I guess that's not as pretty as some other colormaps. If there's some added functionality for smartly choosing colormap ranges based on the data range (as in prettyplotlib), I'd be in favor of a diverging colormap like (RdB_r).

This will become less important if people start adopting the use of style sheets, but I do think defaults are important, regardless.

BTW, after rc parameters are refactored, I was hoping to implement something like cascading style sheets. The hope is that many more config parameters get defined as rc parameters (or maybe "style" parameters after a refactor). Ideally a style sheet would only have to redefine a limited set of parameters to achieve a consistent look.

Here's a simple implementation of a base class for RcParams:
https://github.com/tonysyu/yutils/blob/master/yutils/cascading_config.py

The idea is that you could define a map for specific parameters to more generic parameters, and then only the most generic parameters need to specified:

cascade_map = {'negative.cmap': 'pcolor.cmap',
               'positive.cmap': 'pcolor.cmap',
               'diverging.cmap': 'pcolor.cmap',
               'pcolor.cmap': 'cmap',
               'image.cmap': 'cmap'}

simple_config = {'cmap': 'gray'}
config = CascadingConfig(simple_config, cascade_map=cascade_map)

and get a styling that's consistent for multiple plot types. Styles that want to have more fine-grained control could do something like:

full_config = {'pcolor.cmap': 'Reds',
               'negative.cmap': 'Blues_r',
               'diverging.cmap': 'RdBu_r',
               'cmap': 'gray'}
config = CascadingConfig(full_config, cascade_map=cascade_map)

Yes that looks great!

Olga Botvinnik
PhD Program in Bioinformatics and Systems Biology
Gene Yeo Laboratory | Sanford Consortium for Regenerative Medicine
University of California, San Diego
olgabotvinnik.com
blog.olgabotvinnik.com
github.com/olgabot

On Mon, Sep 30, 2013 at 9:34 PM, Tony S Yu notifications@github.com wrote:

BTW, after rc parameters are refactored, I was hoping to implement
something like cascading style sheets. The hope is that many more config
parameters get defined as rc parameters (or maybe "style" parameters after
a refactor). Ideally a style sheet would only have to redefine a limited
set of parameters to achieve a consistent look.

Here's a simple implementation of a base class for RcParams:
https://github.com/tonysyu/yutils/blob/master/yutils/cascading_config.py

The idea is that you could define a map for specific parameters to more
generic parameters, and then only the most generic parameters need to
specified:

cascade_map = {'negative.cmap': 'pcolor.cmap',
'positive.cmap': 'pcolor.cmap',
'diverging.cmap': 'pcolor.cmap',
'pcolor.cmap': 'cmap',
'image.cmap': 'cmap'}
simple_config = {'cmap': 'gray'}config = CascadingConfig(simple_config, cascade_map=cascade_map)

and get a styling that's consistent for multiple plot types. Styles that
want to have more fine-grained control could do something like:

full_config = {'pcolor.cmap': 'Reds',
'negative.cmap': 'Blues_r',
'diverging.cmap': 'RdBu_r',
'cmap': 'gray'}config = CascadingConfig(full_config, cascade_map=cascade_map)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2467#issuecomment-25424973
.

I think everything reasonable has been implemented here?

Navigation Menu

Repository navigation

Improve default colors and layouts #2467

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Improve default colors and layouts #2467

Description

Activity

tacaswell commented on Sep 27, 2013

mdboom commented on Sep 30, 2013

olgabot commented on Sep 30, 2013

tacaswell commented on Sep 30, 2013

olgabot commented on Sep 30, 2013

tonysyu commented on Oct 1, 2013

tonysyu commented on Oct 1, 2013

olgabot commented on Oct 1, 2013

QuLogic commented on Feb 18, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions