Re: [matplotlib-devel] Better defaults all around?
On Wed, Nov 26, 2014 at 9:30 AM, Todd wrote: > On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On 26 Nov 2014, at 07:53 pm, Chris Barker wrote:
> On Wed, Nov 26, 2014 at 1:30 AM, Todd 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On Wed, Nov 26, 2014 at 1:30 AM, Todd 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 chris.bar...@noaa.gov -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bloomberg Open source sprint, London, November 29-30 2014
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 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 > Matplotlib-devel@lists.sourceforge.net > 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=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bloomberg Open source sprint, London, November 29-30 2014
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith 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). -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
