[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=157005751iu=/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 pelson@gmail.com 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=157005751iu=/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=157005751iu=/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 toddr...@gmail.com 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/ORR(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=157005751iu=/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 chris.bar...@noaa.gov wrote: On Wed, Nov 26, 2014 at 1:30 AM, Todd toddr...@gmail.com 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=157005751iu=/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 9:30 AM, Todd toddr...@gmail.com wrote: On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith n...@pobox.com 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
