matplotlib-devel Mailing List for matplotlib

On Wed, Nov 26, 2014 at 9:30 AM, Todd <tod...@gm...> wrote:
> On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith <nj...@po...> wrote:
>>
>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>> appear to be based on any real theory about visualization -- it's just
>> the corners of the RGB color cube, which is a highly perceptually
>> non-uniform space. The resulting lines aren't terribly high contrast
>> against the default white background, and the different colors have
>> varying luminance that makes some lines "pop out" more than others.
>>
>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>> default:
>>
>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>> also works well. E.g.:
>>
>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
> About this, I am not expert so forgive me if this is nonsensical. However,
> it would seem to me that these requirements are basically the same as the
> requirements for the new default colormap that prompted this whole
> discussion. So, rather than create two inconsistent set of colors that
> accomplish similar goals, might it be better to instead use the default
> colormap for the line colors? You could pick "N" equally-spaced colors from
> the colormap and use those as the line colors.
The main differences in requirements are:
- for the color cycle, you want isoluminant colors, to avoid the issue
where one line is glaring bright red and one is barely-visible-grey.
For general-purpose 2d colormaps, though, you almost always want the
luminance to vary to help distinguish colors from each other.
- for the color cycle, there's no problem with using widely separated
hues -- in fact it's usually better b/c it increases contrast between
the different items, and there's no need to communicate an ordering
between them. But if you try to use the whole hue space in a colormap
then you end up with the much-loathed jet.
-n
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

On 26 Nov 2014, at 07:53 pm, Chris Barker <Chr...@no...> wrote:
> On Wed, Nov 26, 2014 at 1:30 AM, Todd <tod...@gm...> wrote:
>> About this, I am not expert so forgive me if this is nonsensical. However, it would seem to me that these requirements are basically the same as the requirements for the new default colormap that prompted this whole discussion. So, rather than create two inconsistent set of colors that accomplish similar goals, might it be better to instead use the default colormap for the line colors? You could pick "N" equally-spaced colors from the colormap and use those as the line colors.
>> 
> I'm no expert either, but while similar principles about colorblind compatibility, etc apply, you want to sue a different scheme to represent a continuous range of colors and a set of distinct colors that aren't intended to be ranked.
> 
I’ve also become throughly annoyed with the default colour cycle, especially with its
glaring cyan-magenta contrast, and found it desirable to have an easier way to
customise this either explicitly or by changing color_cycle.
As there are already a couple of sequences existing in the available colourmaps that
could be useful for different purposes or tastes, what’s lacking in particular in my view
is an easier-to-use interface to draw colours from those maps; I think that’s along the
lines of what Todd also has suggested further down in his mail.
I’ve written a little utility I’m simply appending because it’s so short, which returns an
array of colours of specified length that could be passed to axes.color_cycle or just
explicitly used as crange[i]. Also useful to colour scatter plot markers according to a
certain quantity (pass this quantity as "values" to crange).
Regarding to the above, I think sometimes the line colour requirements are similar to
those for a general colourmap, e.g. I often want to plot a series of lines like different
spectra, which are easily enough distinguishable, but should IMO reflect a certain
continuous trend like different temperatures - are ranked, IOW - and thus would be well
represented by a sequence of values from "heat" or "coolwarm". However there are still
some additional requirements, as you’d generally want every colour to have enough
contrast on a white or bright background canvas. In the example below I’ve added a
"max_lum" keyword to darken whitish or yellow colours appropriately.
This is probably not extremely sophisticated in terms of colour physiology, but if you
have a suggestion if and where it could be added to matplotlib, I could go ahead and
make a pull request (and try to find the time to add some tests and examples).
Cheers,
						Derek
def crange(cmap, values, max_lum=1, start=0, stop=255, vmin=None, vmax=None):
 """
 Returns RGBA colour array of length values from colormap cmap
 cmap: valid matplotlib.cm colormap name or instance
 values: either int - number of colour values to return or
 array of values to be mapped on colormap range
 max_lum: restrict colours to maximum brightness (1=white)
 start,stop: range of colormap to use (full range 0-255)
 vmin,vmax: input values mapped to start/stop (default actual data limits)
 """
 try:
 if np.isscalar(values):
 vrange = np.linspace(start,stop,np.int(values))
 else:
 v = np.array(values).astype(np.float)
 vmin = vmin or v.min()
 vmax = vmax or v.max()
 vrange = start+(v-vmin)*(stop-start)/(vmax-vmin)
 except (ValueError, TypeError) as err:
 print("invalid input values: must be no. of colours or array: %s" %
 err)
 return None
 vrange = np.uint8(np.round(vrange))
 cmap = matplotlib.cm.get_cmap(cmap)
 lcor = (1.0-max_lum) / 9
 crange = cmap(vrange)
 crange[:,:3] *= (1-crange[:,:3].sum(axis=1)**2*lcor).reshape(-1,1)
 return crange

On Wed, Nov 26, 2014 at 1:30 AM, Todd <tod...@gm...> wrote:
> About this, I am not expert so forgive me if this is nonsensical.
> However, it would seem to me that these requirements are basically the same
> as the requirements for the new default colormap that prompted this whole
> discussion. So, rather than create two inconsistent set of colors that
> accomplish similar goals, might it be better to instead use the default
> colormap for the line colors? You could pick "N" equally-spaced colors
> from the colormap and use those as the line colors.
>
I'm no expert either, but while similar principles about colorblind
compatibility, etc apply, you want to sue a different scheme to represent a
continuous range of colors and a set of distinct colors that aren't
intended to be ranked.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi Phil,
I am in London but busy with other stuff on Saturday. I might be able to
join in on Sunday.
best
Jens
On Wed, Nov 26, 2014 at 11:04 AM, Phil Elson <pel...@gm...> wrote:
> There will be an open source Python sprint, hosted by Bloomberg, this
> weekend in London. The event will be attended by core developers of many of
> the major scientific Python packages (IPython, numpy, scipy, pandas,
> scikit-learn) who will act as mentors to those who would like to get
> involved in the development of these important scientific tools.
>
> I will be attending as a mentor for matplotlib (if there are any other
> core developers who may be able to attend, the more the merrier!) and am
> hoping there will be many attendees who want to get a helping hand getting
> started with matplotlib development. We've got lots of room for
> improvement, from the obvious documentation enhancements right through to
> the nitty-gritty of improving backends such as nbagg.
>
> If you want to come along to the event, please sign-up at
>
> http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/
> .
>
> Hope you see some of you there,
>
> Phil
>
>
> ------------------------------------------------------------------------------
> 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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

There will be an open source Python sprint, hosted by Bloomberg, this
weekend in London. The event will be attended by core developers of many of
the major scientific Python packages (IPython, numpy, scipy, pandas,
scikit-learn) who will act as mentors to those who would like to get
involved in the development of these important scientific tools.
I will be attending as a mentor for matplotlib (if there are any other core
developers who may be able to attend, the more the merrier!) and am hoping
there will be many attendees who want to get a helping hand getting started
with matplotlib development. We've got lots of room for improvement, from
the obvious documentation enhancements right through to the nitty-gritty of
improving backends such as nbagg.
If you want to come along to the event, please sign-up at
http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/
.
Hope you see some of you there,
Phil

On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith <nj...@po...> wrote:
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The resulting lines aren't terribly high contrast
> against the default white background, and the different colors have
> varying luminance that makes some lines "pop out" more than others.
>
> Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
>
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> ggplot2 uses isoluminant colors with maximally-separated hues, which
> also works well. E.g.:
>
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
>
About this, I am not expert so forgive me if this is nonsensical. However,
it would seem to me that these requirements are basically the same as the
requirements for the new default colormap that prompted this whole
discussion. So, rather than create two inconsistent set of colors that
accomplish similar goals, might it be better to instead use the default
colormap for the line colors? You could pick "N" equally-spaced colors
from the colormap and use those as the line colors.
You could even take this a step further, and instead of hard-coding the
line colors, you could make it possible to assign a named colormap to the
line colors parameter. Then there could be a second integer parameter that
determines how many colors to pick from that colormap (it would only do
anything if the line colors are a colormap, otherwise it would be
ignored).

On 22 Nov 2014 02:22, "Benjamin Root" <ben...@ou...> 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.
Nice!
> 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.
Yeah, I didn't want to get into the details of mechanism here because
that's a comparatively simple technical question, compared to the questions
about whether we should make changes and which changes we should make. But
I'm definitely assuming we'll provide a simple supported/documented way to
request the old defaults, and I agree that the obvious way is by swapping
out stylesheets. This might require adding a few more parameters to
rcParam, but I'm guessing that won't be a big deal.
> 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.
Can you elaborate on what you like about it? Like I said, when I first
heard about it sounded like a neat idea. But in practice, over my years of
using matplotlib... sometimes it's been fine, and sometimes it's made me
roll my eyes/swear, but I don't think there's been a single instance where
I looked at a graph and thought "oo, nice one matplotlib - your insistence
on shrinking my data to use fewer pixels in order to get a major tick lined
up exactly with the spines has really improved this graph. Neat tick/spine
alignment really is the highest priority in data visualization".
Even in the rare cases where my measurement scale actually does have a neat
0-1 or 0-100 range, I usually find that matplotlib has chosen something
like 0-90, or, if we fix the issue with cramming data right up into the
axes, then I guess I'll end up with -10 - 110. Which looks worse than
something like -4 - 104, because with -4 - 104, my outermost axis labels
are 0 and 100. With -10 - 110, the outermost labels are -10 and 110, and
it's weird and confusing to have axis labels naming impossible values.
So can you share your examples of where this behavior has given you
substantively better results?
> As for the ticks... I think that is a very obscure edge-case. I
personally prefer inward.
Yeah, that one is a pet peeve - I was gratified to see that the seaborn
folks also took the trouble to fix it (I'm not alone!). To be fair, though,
the reason I noticed isn't that I care a lot about ticks per se, it's
because the default was screwing up my figures so I had to go track it down
:-/. Here's another example -- the final versions of the autocorrelation
graphs I mentioned above.
[image: Inline image 1]
In both of these graphs, having the ticks to point inwards created weird
confusing intersections with the lines, so I had to flip them to point
outwards. It's just an objective thing, if you use the same pixels for data
and metadata then that creates room for ugly stuff to happen. And when it
comes to defaults, if you have two choices that are basically equivalent,
except that one is always fine and one is usually fine but sometimes screws
things up, then the former seems like the obvious choice...
-n