matplotlib-devel Mailing List for matplotlib (Page 2)

Thanks to the response to my previous message, I have managed to get
matplotlib to compile, but unfortunately without the TKAgg backend,
because when I attempt to build, I get the following message:
Tkinter: no
 * Tkinter present, but header files are not found.
 * You may need to install development packages
Looking at setupext.py, this looks like it can't find tk.h in any of
the include directories. But in my win32_static\include folder, I
have got a tk.h. I've tried various locations for the tk headers, but
it still seems to struggle. I even tried setting the basedir setting
in setupext.py to point directly at my tcl;tk library leftover from my
Python compile.
Anyone got any thoughts - this is the last thing I need before I can
actually use matplotlib in my application!
Kind regards
Fred

Thank you for your fast reply,
you are right, AnchoredSizeBar has indeed almost all features I would
like. Or it definitely has the most important ones.
I have stumbled upon the page you refer, but I must have overlooked it.
An actual documentation of the function wouldn't hurt
Anyway, these features seem to be missing:
 - Bar styles (bar width, bar endings wouldn't hurt either).
 - Colors (bar, text, background).
I would like to look into it, but it is usually more efficient if more
experienced persons provide some pointers. So if you think that I should
know something before attempting to add the functionality, please let me
know.
For instance, do you think that the enhancements I have proposed make
sense and should be integrated into AnchoredSizeBar?
Matej
On 11/18/2012 06:32 PM, Joe Kington wrote:
> Have you had a look at "AnchoredSizeBar" from 
> mpl_toolkits.axes_grid1.anchored_artists?
>
> http://matplotlib.org/1.1.1/mpl_toolkits/axes_grid/users/overview.html#anchoredartists
>
> It provides essentially all of the features you mention. I'd agree it 
> could use a few enhancements, but it's a good start on this.
>
> As a quick example of using it as you describe:
>
> import matplotlib.pyplot as plt
> import numpy as np
> from mpl_toolkits.axes_grid1.anchored_artists import AnchoredSizeBar
>
> fig, ax = plt.subplots()
> ax.imshow(np.random.random((10,10)))
>
> bar = AnchoredSizeBar(ax.transData, 2, '2 Units',
> pad=0.5, loc=8, sep=5, borderpad=0.5, frameon=True)
> bar.patch.set(alpha=0.5, boxstyle='round')
> ax.add_artist(bar)
>
> plt.show()
>
>
> Note that this is very similar to your example. The main things it's 
> missing are ends on the scalebar.
>
> I'd certainly agree that it could use some enhancements (e.g. 
> different styles of scalebars and better documentation), but perhaps 
> it's best to start with AnchoredSizeBar instead of recreating it from 
> scratch?
>
> Just my thoughts, anyway.
> -Joe
>
>
> On Sun, Nov 18, 2012 at 8:16 AM, Matěj Týč <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
>
> Dear developers,
> I use Matplotlib to process and display images acquired by
> microscopes.
> It is quite common to indicate dimensions by displaying scale bar
> in the
> image rather than using axes with labels. Although axes enable you to
> refer to specific location in the image, they take up space around the
> image, so if you only need to show the scale, scale bar is better.
>
> What is needed:
> - The scale bar of given dimension (data units), possibly with
> bars at
> its ends.
> - Text (presumably centered under the bar), text size as well as
> vertical offset in physical units (= units reflecting the actual image
> size, like the font size)
> - Semi-transparent rectangle, so the scale and label are more
> readable
> - Dark/bright theme might be a good idea.
> I have made an svg file in Inkscape, so you can see what I mean.
>
> First of all, I tried to implement the stuff myself, but later I have
> found out that there is something on github. I have forked it,
> made some
> minor modifications, and I think that it is "almost done".
> https://gist.github.com/4100881 (the add_scalebar function there is
> broken ATM)
> I also attach the test code for your convenience. You need to run it
> with scalebars.py in the same directory.
> You are supposed to see a tiny bright scalebar at the bottom right
> corner.
>
> There are some outstanding issues, though:
>
> - I have a feeling that bars at the end of the scale bar should be
> related to the font size, as well as the actual width of the scale
> bar.
> How to achieve this?
> - How to make the semi-transparent background for the bar and
> label in
> a smart way?
>
> Could you help me with those? I would like this to appear in
> matplotlib
> since it is IMO a useful feature, what needs to be done?
> Regards,
> Matěj Týč
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases,
> vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

http://matplotlib.org/devel/coding_guide.html
Scroll down to 'Testing'. Click 'Testing'. Boom.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 11/20/2012 5:55 AM, Fred Pollard wrote:
> I'm in the process of completing an application with an embedded
> Python 2.7.3 interpreter - but it all has to be compiled against
> VS2010.
>
> Have managed Python and it's dependencies, as well as numpy 1.6.2, but
> struggling with matplotlib because I can't get the dependencies to
> compile properly - mainly libpng, which seems to demand .lib and .dll
> files that a compilation of zlib from source does not produce (e.g.
> zdll.lib, zlib.lib, etc.). I know Christophe Gohlke has kindly
> produced a set of dependencies up to VS2008. Does anyone know of an
> existing similar set compiled for VS 2010?
>
> Many thanks,
> Fred
>
Hi Fred,
I updated "matplotlib-1.x-windows-link-libraries.zip" with dependencies 
compiled for VS 2010. Let me know if anything is missing.
Christoph

I'm in the process of completing an application with an embedded
Python 2.7.3 interpreter - but it all has to be compiled against
VS2010.
Have managed Python and it's dependencies, as well as numpy 1.6.2, but
struggling with matplotlib because I can't get the dependencies to
compile properly - mainly libpng, which seems to demand .lib and .dll
files that a compilation of zlib from source does not produce (e.g.
zdll.lib, zlib.lib, etc.). I know Christophe Gohlke has kindly
produced a set of dependencies up to VS2008. Does anyone know of an
existing similar set compiled for VS 2010?
Many thanks,
Fred

I just sent this to the matplotlib-users list, but noticed it's been abandoned, or at least unused since August. I'm reposting here and adding the info I forgot on the other list. Sorry if you get this twice.
This is running matplotlib 1.1.1 installed with pip on
Linux savoie 2.6.32.59-0.7-default #1 SMP 2012年07月13日 15:50:56 +0200 x86_64 x86_64 x86_64 GNU/Linux
(But I also tested with MPL:1.2)
Hi there, 
I've boiled down a problem and while the following my look useless, I need to understand why matplotlib is behaving like it is.
Below is code showing my issue. I don't believe the issue is with the "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400, but the last row is a row of transparent pixels(on linux/not mac). It's difficult to see unless you use the imagemagik command display.
The basic problem is that when my data has an aspect ratio very close to 1.75, the image gets changed to one with an aspect of 1.74875.
Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio.
Incorrect figure info => 800x1399 => 1.74875
Data that works aspect ratio: 1.7499999999999998
Data that fails aspect ratio: 1.7499999999999996
---> Srsly?! -------------------------------^
It would be great if someone could explain to me what's happening if this is indeed working as expected. If it's not, it would be great if someone could fix it.
Thanks in advance.
Matt
import matplotlib.pyplot as plt
def create_image():
 # I want an 800x1400 image (aspect = 1400/800 = 1.75.
 fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100)
 # Use the whole figure and fill with a patch.
 fig.add_axes([0, 0, 1, 1])
 ax = plt.gca()
 limb = ax.axesPatch
 limb.set_facecolor('#6587ad')
 # Set some bounds with Aspects very close to the desired aspect ratios.
 x1 = 0.0
 y1 = 0.0
 x2 = 16.
 # If you un-comment out this line (and comment the one below). I get an image I expect
 # y2 = 27.999999999999994671 # produces 800 x 1400 image
 # aspect = 1.7499999999999998 works
 # Use this line and I get and image the wrong size (or with transparent pixels.)
 y2 = 27.999999999999994670 # produces (wrong?) 800 x 1399 image
 # aspect = 1.7499999999999996 Fails? wat?
 corners = ((x1, y1), (x2, y2))
 ax.update_datalim(corners)
 ax.set_xlim((x1, x2))
 ax.set_ylim((y1, y2))
 ax.set_aspect('equal', anchor='C')
 ax.set_xticks([])
 ax.set_yticks([])
 plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight')
 # If you use this below, the file size is correct, but there is a single
 # line transparent pixels along the bottom of the image
 # plt.savefig('rectangle.png', pad_inches=0.0)
if __name__ == '__main__':
 create_image()

Dear developers,
I use Matplotlib to process and display images acquired by microscopes.
It is quite common to indicate dimensions by displaying scale bar in the
image rather than using axes with labels. Although axes enable you to
refer to specific location in the image, they take up space around the
image, so if you only need to show the scale, scale bar is better.
What is needed:
 - The scale bar of given dimension (data units), possibly with bars at
its ends.
 - Text (presumably centered under the bar), text size as well as
vertical offset in physical units (= units reflecting the actual image
size, like the font size)
 - Semi-transparent rectangle, so the scale and label are more readable
 - Dark/bright theme might be a good idea.
I have made an svg file in Inkscape, so you can see what I mean.
First of all, I tried to implement the stuff myself, but later I have
found out that there is something on github. I have forked it, made some
minor modifications, and I think that it is "almost done". 
https://gist.github.com/4100881 (the add_scalebar function there is
broken ATM)
I also attach the test code for your convenience. You need to run it
with scalebars.py in the same directory.
You are supposed to see a tiny bright scalebar at the bottom right
corner.
There are some outstanding issues, though:
 - I have a feeling that bars at the end of the scale bar should be
related to the font size, as well as the actual width of the scale bar.
How to achieve this?
 - How to make the semi-transparent background for the bar and label in
a smart way?
Could you help me with those? I would like this to appear in matplotlib
since it is IMO a useful feature, what needs to be done?
Regards,
Matěj Týč

On Sat, Nov 17, 2012 at 4:07 PM, Cyrille Rossant
<cyr...@gm...> wrote:
> OK so I now have a very experimental proof of concept of how integrating
> Galry in the IPython notebook. There's a short demo here:
> http://www.youtube.com/watch?v=taN4TobRS-E
>
> I'll put the code on github but there's of course much more to do.
>
> I'll also work on a basic matplotlib-like high-level interface that will
> work in both standard python/ipython consoles, and in the IPython notebook.
Awesome! This is really great to see, before long we'll sort out
these APIs so all this can be made available easily to end users.
Great job!
Cheers,
f

Thanks everyone for the feedback.
yeah -- scipy dependency is just a joke, as I said, since only sem is in
use, so would be trivial to 'fix'.
As for where to contribute unless to matplotlib -- I would have just
sticked it in our own PyMVPA ;) but I think those would be generally
useful, so I will just try to cook up a proper PR against matplotlib
some time next week and then go from there.
Cheers!
On 2012年11月16日, Paul Hobson wrote:
> [4]http://nbviewer.ipython.org/url/www.onerussian.com/tmp/run_plots.ipynb
> > I wonder if there is a need/place for it in matplotlib and what
> changes would
> > you advise. Sorry for the lack of documentation -- I guess I have not
> finished
> > it at that point (scipy dependency can easily be dropped, used only
> for
> > standard error function iirc):
> Looks nice. We'd certainly be interesting in including it in
> statsmodels/graphics if there isn't sufficient interest here and/or
> you'd like to keep the scipy dependency. ;)
> I was going to suggest either the same thing or adding it to pandas. I
> think statsmodels if the better fit, though. I also noticed scipy is only
> used for scipy.stats.sem -- so it might be easy enough to loose the scipy
> dependency. Just a thought.
-- 
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik 

>
> Yup, it's a bit of a hack right now b/c you need to merge several
>> branches and tools that are still in review, but it's not too bad.
>>
>> You need to start from this branch:
>>
>> https://github.com/ellisonbg/ipython/tree/jsonhandlers
>>
>> and then grab this repo:
>>
>> https://github.com/ipython/jsplugins
>>
>> I would start by testing the d3graph plugin and verify that you can do
>> what I show here (watch ~ 40 seconds):
>>
>> http://www.youtube.com/watch?v=F4rFuIb1Ie4&t=40m0s
>>
>> That should give you the basics. Then the webgl visualizer example is
>> here:
>>
>> https://github.com/RishiRamraj/seepymol
>>
>
OK so I now have a very experimental proof of concept of how integrating
Galry in the IPython notebook. There's a short demo here:
http://www.youtube.com/watch?v=taN4TobRS-E
I'll put the code on github but there's of course much more to do.
I'll also work on a basic matplotlib-like high-level interface that will
work in both standard python/ipython consoles, and in the IPython notebook.
Cheers,
Cyrille

>
> Yup, it's a bit of a hack right now b/c you need to merge several
> branches and tools that are still in review, but it's not too bad.
>
> You need to start from this branch:
>
> https://github.com/ellisonbg/ipython/tree/jsonhandlers
>
> and then grab this repo:
>
> https://github.com/ipython/jsplugins
>
> I would start by testing the d3graph plugin and verify that you can do
> what I show here (watch ~ 40 seconds):
>
> http://www.youtube.com/watch?v=F4rFuIb1Ie4&t=40m0s
>
> That should give you the basics. Then the webgl visualizer example is
> here:
>
> https://github.com/RishiRamraj/seepymol
>
> Cheers,
>
> f
>
Great, thanks! I'll take a look to that and get back to you when I have
something.
Cheers,
Cyrille

Hi Cyrille,
On Fri, Nov 16, 2012 at 1:00 PM, Cyrille Rossant
<cyr...@gm...> wrote:
> Hi Fernando,
>
> It would be really great if galry could be integrated in the notebook
> indeed. Is the code of this demo available somewhere, so that I can get an
> idea about how this integration works?
>
> In theory, galry should be compatible with WebGL because one of the main
> components of galry is a shader code generator that can produce OpenGL
> ES-compatible GLSL code. Apart from that, I suppose you have some way of
> making Javascript and Python communicate? The interaction system of Galry,
> which is based on QT but with an abstraction layer, could then be plugged to
> Javascript somehow... Anyway, if I could take a look to the code of this
> demo, I should be able to evaluate how complicated this integration would
> be.
Yup, it's a bit of a hack right now b/c you need to merge several
branches and tools that are still in review, but it's not too bad.
You need to start from this branch:
https://github.com/ellisonbg/ipython/tree/jsonhandlers
and then grab this repo:
https://github.com/ipython/jsplugins
I would start by testing the d3graph plugin and verify that you can do
what I show here (watch ~ 40 seconds):
http://www.youtube.com/watch?v=F4rFuIb1Ie4&t=40m0s
That should give you the basics. Then the webgl visualizer example is here:
https://github.com/RishiRamraj/seepymol
Cheers,
f

Hi Fernando,
It would be really great if galry could be integrated in the
notebook indeed. Is the code of this demo available somewhere, so that I
can get an idea about how this integration works?
In theory, galry should be compatible with WebGL because one of the main
components of galry is a shader code generator that can produce OpenGL
ES-compatible GLSL code. Apart from that, I suppose you have some way of
making Javascript and Python communicate? The interaction system of Galry,
which is based on QT but with an abstraction layer, could then be plugged
to Javascript somehow... Anyway, if I could take a look to the code of this
demo, I should be able to evaluate how complicated this integration would
be.
Cyrille
2012年11月16日 Fernando Perez <fpe...@gm...>
> Hi Cyrille,
>
> On Thu, Nov 15, 2012 at 11:24 AM, Cyrille Rossant
> <cyr...@gm...> wrote:
> > I am developing a high-performance interactive visualization package in
> > Python based on PyOpenGL (http://rossant.github.com/galry/). It is
> primarily
> > meant to be used as a framework for developing complex interactive GUIs
> (in
> > QT) that deal with very large amounts of data (tens of millions of
> points).
> > But it may also be used, like matplotlib, as a high-level interactive
> > library to plot and visualize data.
>
> quick question: how easy/feasible is WebGL integration? I ask b/c
> we're starting to get the necessary machinery for easy WebGL
> visualization in the ipython notebook, see e.g.:
>
> http://www.flickr.com/photos/47156828@N06/8183294725
>
> so bringing galry to the notebook with minimal code duplication would
> be great. I just mention it now in case it helps you make design
> decisions as you go along.
>
> Cheers,
>
> f
>

Hi Cyrille,
On Thu, Nov 15, 2012 at 11:24 AM, Cyrille Rossant
<cyr...@gm...> wrote:
> I am developing a high-performance interactive visualization package in
> Python based on PyOpenGL (http://rossant.github.com/galry/). It is primarily
> meant to be used as a framework for developing complex interactive GUIs (in
> QT) that deal with very large amounts of data (tens of millions of points).
> But it may also be used, like matplotlib, as a high-level interactive
> library to plot and visualize data.
quick question: how easy/feasible is WebGL integration? I ask b/c
we're starting to get the necessary machinery for easy WebGL
visualization in the ipython notebook, see e.g.:
http://www.flickr.com/photos/47156828@N06/8183294725
so bringing galry to the notebook with minimal code duplication would
be great. I just mention it now in case it helps you make design
decisions as you go along.
Cheers,
f

On Fri, Nov 16, 2012 at 7:58 AM, Skipper Seabold <jss...@gm...>wrote:
> On Fri, Nov 16, 2012 at 10:19 AM, Yaroslav Halchenko <sf...@on...>
> wrote:
> > I just found some code (http://www.onerussian.com/tmp/plots.py and
> > pasted below for review/feedback) laying around which I wrote around
> > matplotlib for plotting primarily pair-wise stats results. Here is a
> > demonstration:
> > http://nbviewer.ipython.org/url/www.onerussian.com/tmp/run_plots.ipynb
> >
> > I wonder if there is a need/place for it in matplotlib and what changes
> would
> > you advise. Sorry for the lack of documentation -- I guess I have not
> finished
> > it at that point (scipy dependency can easily be dropped, used only for
> > standard error function iirc):
> >
>
> Looks nice. We'd certainly be interesting in including it in
> statsmodels/graphics if there isn't sufficient interest here and/or
> you'd like to keep the scipy dependency. ;)
>
> Skipper
I was going to suggest either the same thing or adding it to pandas. I
think statsmodels if the better fit, though. I also noticed scipy is only
used for scipy.stats.sem -- so it might be easy enough to loose the scipy
dependency. Just a thought.
-paul

On Fri, Nov 16, 2012 at 10:19 AM, Yaroslav Halchenko <sf...@on...> wrote:
> I just found some code (http://www.onerussian.com/tmp/plots.py and
> pasted below for review/feedback) laying around which I wrote around
> matplotlib for plotting primarily pair-wise stats results. Here is a
> demonstration:
> http://nbviewer.ipython.org/url/www.onerussian.com/tmp/run_plots.ipynb
>
> I wonder if there is a need/place for it in matplotlib and what changes would
> you advise. Sorry for the lack of documentation -- I guess I have not finished
> it at that point (scipy dependency can easily be dropped, used only for
> standard error function iirc):
>
Looks nice. We'd certainly be interesting in including it in
statsmodels/graphics if there isn't sufficient interest here and/or
you'd like to keep the scipy dependency. ;)
Skipper
> #!/usr/bin/python
> #emacs: -*- mode: python-mode; py-indent-offset: 4; tab-width: 4; indent-tabs-mode: nil -*-
> #ex: set sts=4 ts=4 sw=4 noet:
> #------------------------- =+- Python script -+= -------------------------
> """
> @file paired-plots.py
> @date Fri Jan 13 11:48:00 2012
> @brief
>
>
> Yaroslav Halchenko Dartmouth
> web: http://www.onerussian.com College
> e-mail: yo...@on... ICQ#: 60653192
>
> DESCRIPTION (NOTES):
>
> COPYRIGHT: Yaroslav Halchenko 2012
>
> LICENSE: MIT
>
> Permission is hereby granted, free of charge, to any person obtaining a copy
> of this software and associated documentation files (the "Software"), to deal
> in the Software without restriction, including without limitation the rights
> to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> copies of the Software, and to permit persons to whom the Software is
> furnished to do so, subject to the following conditions:
>
> The above copyright notice and this permission notice shall be included in
> all copies or substantial portions of the Software.
>
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE SOFTWARE.
> """
> #-----------------\____________________________________/------------------
>
> __author__ = 'Yaroslav Halchenko'
> __revision__ = '$Revision: $'
> __date__ = '$Date: $'
> __copyright__ = 'Copyright (c) 2012 Yaroslav Halchenko'
> __license__ = 'MIT'
>
>
> import numpy as np
> import pylab as pl
> import scipy.stats as ss
>
> def plot_boxplot_enhanced(
> v,
> contrast_labels=None,
> condition_labels=None,
> ccolors=['y', 'b'],
> rand_offsets=None,
> grid=True,
> xticks_rotation=0,
> **bp_kwargs):
>
> width = bp_kwargs.get('width', 0.5)
> pl.boxplot(v, **bp_kwargs)
>
> if v.ndim < 2: v = v[:, None]
> ncol = v.shape[1]
>
> eff = np.mean(v, axis=0) # effect sizes
> sem = ss.sem(v, axis=0)
>
> if rand_offsets is None:
> rand_offsets = np.random.randn(len(v)) * 0.02
>
> pl.plot((np.arange(ncol) + 1)[:, None] + rand_offsets,
> v.T, '.', color='k', markerfacecolor='k')
> for i in range(ncol):
> lw = 2
> pl.plot([1 - width/2. + i, 1+i],
> [0, 0],
> '--', color=ccolors[0], linewidth=lw) # first condition
> pl.plot([1+i, 1 + width/2. +i],
> [eff[i]]*2,
> '--', color=ccolors[1], linewidth=lw)
>
> # place ste
> pl.errorbar(i+1 + 1.1*width/2.,
> eff[i],
> sem[i],
> elinewidth=2, linewidth=0,
> color='r', ecolor='r')
>
> if contrast_labels and not i: # only for the first one
> pl.text(1 - 1.1*width/2 + i, 0.1, contrast_labels[0],
> verticalalignment='bottom',
> horizontalalignment='right')
> pl.text(1 + 1.2*width/2 + i, eff[i], contrast_labels[1],
> verticalalignment='bottom', horizontalalignment='left')
> ax = pl.gca()
> if condition_labels:
> ax.set_xticklabels(condition_labels, rotation=xticks_rotation)
> else:
> # hide it
> ax.axes.xaxis.set_visible(False)
>
> if grid:
> ax.grid()
> return ax
>
>
> def plot_paired_stats(
> v0, v1, contrast_labels,
> condition_labels=None,
> style=['barplot_effect',
> 'boxplot_raw',
> 'boxplot_effect'],
> ccolors=['y', 'g'],
> xticks_rotation=0,
> grid=False,
> fig=None,
> bottom_adjust=None,
> bp_kwargs={}):
>
> if isinstance(style, str):
> style = [style]
>
> nplots = len(style) # how many subplots will be needed
>
> # assure having 2nd dimension
> if v0.ndim < 2: v0 = v0[:, None]
> if v1.ndim < 2: v1 = v1[:, None]
> assert(v0.shape == v1.shape)
>
> ncol = v0.shape[1]
> v10 = (v1 - v0) # differences
> mv0 = np.mean(v0, axis=0) # means
> mv1 = np.mean(v1, axis=0)
>
> eff = np.mean(v10, axis=0) # effect sizes
> sem = ss.sem(v10, axis=0)
>
> # so that data points have are distinguishable
> rand_offsets = np.random.randn(len(v10)) * 0.02
>
> # interleaved combination for some plots
> v_ = np.hstack((v0, v1))
> v = np.zeros(v_.shape, dtype=v_.dtype)
> v[:, np.hstack((np.arange(0, ncol*2, 2),
> np.arange(1, ncol*2, 2)))] = v_
>
> #print v.shape
> #print np.mean(v0, axis=0), np.mean(v1, axis=0)
> #print np.min(v10, axis=0), np.max(v10, axis=0), \
> # np.mean(v10, axis=0), ss.sem(v10, axis=0)
> #pl.boxplot(v10 + np.mean(v1), notch=1, widths=0.05)
>
> #print v0.shape, v1.shape, np.hstack([v0, v1]).shape
>
> if fig is None:
> fig = pl.figure()
>
> bwidth = 0.5
> plot = 1
>
> if condition_labels:
> xlabels = [ '%s:%s' % (cond, contr)
> for cond in condition_labels
> for contr in contrast_labels ]
> else:
> xlabels = contrast_labels
>
> bp_kwargs_ = {
> #'bootstrap': 0,
> 'notch' : 1
> }
> bp_kwargs_.update(bp_kwargs)
>
> def plot_grid(ax):
> if grid:
> ax.grid()
>
> if 'barplot_effect' in style:
> if len(style) > 1:
> pl.subplot(1, nplots, plot)
> plot += 1
> # The simplest one
> pl.bar(np.arange(1, ncol*2+1) - bwidth/2,
> np.mean(v, axis=0),
> color=ccolors*ncol,
> edgecolor=ccolors*ncol,
> alpha=0.8,
> width=bwidth)
> #pl.minorticks_off()
> pl.tick_params('x', direction='out', length=6, width=1,
> top=False)
> ax = pl.gca()
> pl.xlim(0.5, ncol*2+0.5)
> ax.set_xticks(np.arange(1, ncol*2+1))
> ax.set_xticklabels(xlabels, rotation=xticks_rotation)
> # place ste for effect size into the 2nd column
> pl.errorbar(np.arange(ncol)*2+2,
> mv1,
> sem, elinewidth=2, linewidth=0,
> color='g', ecolor='r')
>
> plot_grid(ax)
>
> if 'boxplot_raw' in style:
> if len(style) > 1:
> pl.subplot(1, nplots, plot)
> plot += 1
>
> # Figure 1 -- "raw" data
> # plot "connections" between boxplots
> for i in range(ncol):
> pargs = (np.array([i*2+1, i*2+2])[:, None] + rand_offsets,
> np.array([v0[:,i], v1[:,i]]))
> pl.plot(*(pargs+('-',)), color='k', alpha=0.5, linewidth=0.25)
> pl.plot(*(pargs+('.',)), color='k', alpha=0.9)
> # boxplot of "raw" data
> bp1 = pl.boxplot(v, widths=bwidth, **bp_kwargs_)
> for i in range(ncol):
> for c in xrange(2):
> b = bp1['boxes'][2*i+c]
> b.set_color(ccolors[c])
> b.set_linewidth(2)
>
> ax = pl.gca()
> ax.set_xticklabels(xlabels, rotation=xticks_rotation)
> plot_grid(ax)
>
> if 'boxplot_effect' in style:
> if len(style) > 1:
> pl.subplot(1, nplots, plot)
> plot += 1
> plot_boxplot_enhanced(v10,
> contrast_labels=contrast_labels,
> condition_labels=condition_labels,
> widths=bwidth,
> rand_offsets=rand_offsets, # reuse them
> grid=grid,
> **bp_kwargs_)
>
> if bottom_adjust:
> fig.subplots_adjust(bottom=bottom_adjust)
> pl.draw_if_interactive()
> return fig
>
> if __name__ == '__main__':
>
> if True:
> v = np.random.normal(size=(50,8)) * 20 + 120
> if False:
> v[:, 1] += 40
> v[:, 3] -= 30
> v[:, 5] += 60
> v[:, 6] -= 60
> else:
> v -= np.arange(v.shape[1])*10
> v /= 10
>
> v0 = v[:, ::2]
> v1 = v[:, 1::2]
> d = v1 - v0
> print np.mean(d, axis=0)
> styles = ['barplot_effect',
> 'boxplot_raw',
> 'boxplot_effect'
> ]
> styles = styles + [styles]
> pl.close('all')
>
> if False:
> f = plot_boxplot_enhanced((v1-v0)[:,0],
> grid=True, xticks_rotation=30, notch=1)
>
> for s in styles:
> fig = pl.figure(figsize=(12,6))
> f = plot_paired_stats(v0, v1, ['cont1', 'cont2'],
> style=s, fig=fig,
> condition_labels=['exp1', 'exp2', 'exp3', 'exp4'],
> grid=True, xticks_rotation=30)
> pl.show()
>
>
> --
> Yaroslav O. Halchenko
> Postdoctoral Fellow, Department of Psychological and Brain Sciences
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I just found some code (http://www.onerussian.com/tmp/plots.py and
pasted below for review/feedback) laying around which I wrote around
matplotlib for plotting primarily pair-wise stats results. Here is a
demonstration:
http://nbviewer.ipython.org/url/www.onerussian.com/tmp/run_plots.ipynb
I wonder if there is a need/place for it in matplotlib and what changes would
you advise. Sorry for the lack of documentation -- I guess I have not finished
it at that point (scipy dependency can easily be dropped, used only for
standard error function iirc):
#!/usr/bin/python
#emacs: -*- mode: python-mode; py-indent-offset: 4; tab-width: 4; indent-tabs-mode: nil -*- 
#ex: set sts=4 ts=4 sw=4 noet:
#------------------------- =+- Python script -+= -------------------------
"""
 @file paired-plots.py
 @date Fri Jan 13 11:48:00 2012
 @brief
 Yaroslav Halchenko Dartmouth
 web: http://www.onerussian.com College
 e-mail: yo...@on... ICQ#: 60653192
 DESCRIPTION (NOTES):
 COPYRIGHT: Yaroslav Halchenko 2012
 LICENSE: MIT
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in
 all copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 THE SOFTWARE.
"""
#-----------------\____________________________________/------------------
__author__ = 'Yaroslav Halchenko'
__revision__ = '$Revision: $'
__date__ = '$Date: $'
__copyright__ = 'Copyright (c) 2012 Yaroslav Halchenko'
__license__ = 'MIT'
import numpy as np
import pylab as pl
import scipy.stats as ss
def plot_boxplot_enhanced(
 v,
 contrast_labels=None,
 condition_labels=None,
 ccolors=['y', 'b'],
 rand_offsets=None,
 grid=True,
 xticks_rotation=0,
 **bp_kwargs):
 width = bp_kwargs.get('width', 0.5)
 pl.boxplot(v, **bp_kwargs)
 if v.ndim < 2: v = v[:, None]
 ncol = v.shape[1]
 eff = np.mean(v, axis=0) # effect sizes
 sem = ss.sem(v, axis=0)
 if rand_offsets is None:
 rand_offsets = np.random.randn(len(v)) * 0.02
 pl.plot((np.arange(ncol) + 1)[:, None] + rand_offsets,
 v.T, '.', color='k', markerfacecolor='k')
 for i in range(ncol):
 lw = 2
 pl.plot([1 - width/2. + i, 1+i],
 [0, 0],
 '--', color=ccolors[0], linewidth=lw) # first condition
 pl.plot([1+i, 1 + width/2. +i],
 [eff[i]]*2,
 '--', color=ccolors[1], linewidth=lw)
 # place ste
 pl.errorbar(i+1 + 1.1*width/2.,
 eff[i],
 sem[i],
 elinewidth=2, linewidth=0,
 color='r', ecolor='r')
 if contrast_labels and not i: # only for the first one
 pl.text(1 - 1.1*width/2 + i, 0.1, contrast_labels[0],
 verticalalignment='bottom',
 horizontalalignment='right')
 pl.text(1 + 1.2*width/2 + i, eff[i], contrast_labels[1],
 verticalalignment='bottom', horizontalalignment='left')
 ax = pl.gca()
 if condition_labels:
 ax.set_xticklabels(condition_labels, rotation=xticks_rotation)
 else:
 # hide it
 ax.axes.xaxis.set_visible(False)
 if grid:
 ax.grid()
 return ax
def plot_paired_stats(
 v0, v1, contrast_labels,
 condition_labels=None,
 style=['barplot_effect',
 'boxplot_raw',
 'boxplot_effect'],
 ccolors=['y', 'g'],
 xticks_rotation=0,
 grid=False,
 fig=None,
 bottom_adjust=None,
 bp_kwargs={}):
 if isinstance(style, str):
 style = [style]
 nplots = len(style) # how many subplots will be needed
 # assure having 2nd dimension
 if v0.ndim < 2: v0 = v0[:, None]
 if v1.ndim < 2: v1 = v1[:, None]
 assert(v0.shape == v1.shape)
 ncol = v0.shape[1]
 v10 = (v1 - v0) # differences
 mv0 = np.mean(v0, axis=0) # means
 mv1 = np.mean(v1, axis=0)
 eff = np.mean(v10, axis=0) # effect sizes
 sem = ss.sem(v10, axis=0)
 # so that data points have are distinguishable
 rand_offsets = np.random.randn(len(v10)) * 0.02
 # interleaved combination for some plots
 v_ = np.hstack((v0, v1))
 v = np.zeros(v_.shape, dtype=v_.dtype)
 v[:, np.hstack((np.arange(0, ncol*2, 2),
 np.arange(1, ncol*2, 2)))] = v_
 #print v.shape
 #print np.mean(v0, axis=0), np.mean(v1, axis=0)
 #print np.min(v10, axis=0), np.max(v10, axis=0), \
 # np.mean(v10, axis=0), ss.sem(v10, axis=0)
 #pl.boxplot(v10 + np.mean(v1), notch=1, widths=0.05)
 #print v0.shape, v1.shape, np.hstack([v0, v1]).shape
 if fig is None:
 fig = pl.figure()
 bwidth = 0.5
 plot = 1
 if condition_labels:
 xlabels = [ '%s:%s' % (cond, contr)
 for cond in condition_labels
 for contr in contrast_labels ]
 else:
 xlabels = contrast_labels
 bp_kwargs_ = {
 #'bootstrap': 0,
 'notch' : 1
 }
 bp_kwargs_.update(bp_kwargs)
 def plot_grid(ax):
 if grid:
 ax.grid()
 if 'barplot_effect' in style:
 if len(style) > 1:
 pl.subplot(1, nplots, plot)
 plot += 1
 # The simplest one
 pl.bar(np.arange(1, ncol*2+1) - bwidth/2,
 np.mean(v, axis=0),
 color=ccolors*ncol,
 edgecolor=ccolors*ncol,
 alpha=0.8,
 width=bwidth)
 #pl.minorticks_off()
 pl.tick_params('x', direction='out', length=6, width=1,
 top=False)
 ax = pl.gca()
 pl.xlim(0.5, ncol*2+0.5)
 ax.set_xticks(np.arange(1, ncol*2+1))
 ax.set_xticklabels(xlabels, rotation=xticks_rotation)
 # place ste for effect size into the 2nd column
 pl.errorbar(np.arange(ncol)*2+2,
 mv1,
 sem, elinewidth=2, linewidth=0,
 color='g', ecolor='r')
 plot_grid(ax)
 if 'boxplot_raw' in style:
 if len(style) > 1:
 pl.subplot(1, nplots, plot)
 plot += 1
 # Figure 1 -- "raw" data
 # plot "connections" between boxplots
 for i in range(ncol):
 pargs = (np.array([i*2+1, i*2+2])[:, None] + rand_offsets,
 np.array([v0[:,i], v1[:,i]]))
 pl.plot(*(pargs+('-',)), color='k', alpha=0.5, linewidth=0.25)
 pl.plot(*(pargs+('.',)), color='k', alpha=0.9)
 # boxplot of "raw" data
 bp1 = pl.boxplot(v, widths=bwidth, **bp_kwargs_)
 for i in range(ncol):
 for c in xrange(2):
 b = bp1['boxes'][2*i+c]
 b.set_color(ccolors[c])
 b.set_linewidth(2)
 ax = pl.gca()
 ax.set_xticklabels(xlabels, rotation=xticks_rotation)
 plot_grid(ax)
 if 'boxplot_effect' in style:
 if len(style) > 1:
 pl.subplot(1, nplots, plot)
 plot += 1
 plot_boxplot_enhanced(v10,
 contrast_labels=contrast_labels,
 condition_labels=condition_labels,
 widths=bwidth,
 rand_offsets=rand_offsets, # reuse them
 grid=grid,
 **bp_kwargs_)
 if bottom_adjust:
 fig.subplots_adjust(bottom=bottom_adjust)
 pl.draw_if_interactive()
 return fig
if __name__ == '__main__':
 if True:
 v = np.random.normal(size=(50,8)) * 20 + 120
 if False:
 v[:, 1] += 40
 v[:, 3] -= 30
 v[:, 5] += 60
 v[:, 6] -= 60
 else:
 v -= np.arange(v.shape[1])*10
 v /= 10
 v0 = v[:, ::2]
 v1 = v[:, 1::2]
 d = v1 - v0
 print np.mean(d, axis=0)
 styles = ['barplot_effect',
 'boxplot_raw',
 'boxplot_effect'
 ]
 styles = styles + [styles]
 pl.close('all')
 if False:
 f = plot_boxplot_enhanced((v1-v0)[:,0],
 grid=True, xticks_rotation=30, notch=1)
 for s in styles:
 fig = pl.figure(figsize=(12,6))
 f = plot_paired_stats(v0, v1, ['cont1', 'cont2'],
 style=s, fig=fig,
 condition_labels=['exp1', 'exp2', 'exp3', 'exp4'],
 grid=True, xticks_rotation=30)
 pl.show()
-- 
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik 

On Fri, Nov 16, 2012 at 7:44 AM, Mike Kaufman <mc...@gm...> wrote:
> On 11/15/12 2:54 PM, Paul Ivanov wrote:
> > On Wed, Nov 14, 2012 at 7:37 PM, Mike Kaufman <mc...@gm...
>
> >
> > I just found that *direction* accepts 'inout' as well, which
> > does indeed place the tick on both sides of the spine. So the
> > documentation should be updated to reflect this.
> >
> >
> > Thanks for the report, Mike, here's a PR for the patch:
> > https://github.com/matplotlib/matplotlib/pull/1503
> >
> > If it were me, I'd allow 'both' to work as well.
> >
> >
> > I'm amenable to that, just not sure if that counts as a new feature and
> > should go into master, or a bugfix and go into v1.2.x.
> >
> > I can add this functionality to #1503 if that makes sense to go to v1.2.x
>
> Thanks Paul,
>
> One is a doc fix, the other requires changing code (inside axis.py?). So
> best practice probably argues that 'both', if acceptable, should really
> only go into master.
>
> That said, I think the 'both' change only requires a change to a pair of
> conditionals...
>
> M
>
>
I agree with the fact that implementing "both" to mean the same as "inout"
should go into master only.
Ben Root

On 11/15/12 2:54 PM, Paul Ivanov wrote:
> On Wed, Nov 14, 2012 at 7:37 PM, Mike Kaufman <mc...@gm...
>
> I just found that *direction* accepts 'inout' as well, which
> does indeed place the tick on both sides of the spine. So the
> documentation should be updated to reflect this.
>
>
> Thanks for the report, Mike, here's a PR for the patch:
> https://github.com/matplotlib/matplotlib/pull/1503
>
> If it were me, I'd allow 'both' to work as well.
>
>
> I'm amenable to that, just not sure if that counts as a new feature and
> should go into master, or a bugfix and go into v1.2.x.
>
> I can add this functionality to #1503 if that makes sense to go to v1.2.x
Thanks Paul,
One is a doc fix, the other requires changing code (inside axis.py?). So 
best practice probably argues that 'both', if acceptable, should really 
only go into master.
That said, I think the 'both' change only requires a change to a pair of 
conditionals...
M

On 16 November 2012 05:14, Damon McDougall <dam...@gm...>wrote:
> >> I have a C++ TriFinder class
> >> that I could modify to work within matplotlib, and it is O(log N) so
> should
> >> be faster than your version for typical use cases.
> >
> > What algorithm does this use? Is the code open source and/or availabel
> > for other projects?
>
> I'm pretty sure there is an O(log n) algorithm in the Numerical
> Recipes book. It requires you to construct the triangulation in a
> specific way (this allows one to set up a tree data structure of
> triangles nicely). There may be others that I am not aware of though.
>
I think this is the standard method used for point-in-triangulation tests
for delaunay triangulations, as the search structure is created as the
triangulation is built. We need to support non-delaunay triangulations
that are specified by the user, which requires a different approach.
Ian

On 15 November 2012 21:25, Chris Barker <chr...@no...> wrote:
> On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas <ian...@gm...> wrote:
>
> > I think the code used to determine which triangle contains a certain
> point
> > should be factored out into its own TriFinder class,
>
> +1 -- this is a generally useful feature. In fact, it would be nice if
> a lot of this were in a pacakge that deals with triangular meshes,
> apart from MPL altogether (a scikit maybe?)
>
I hadn't considered any wider interest in it. From a selfish matplotlib
point of view, even if it was in say a scikit, we wouldn't want to add an
external dependency to the scikit so we would still need a copy of the
source code within matplotlib anyway, just to do our interpolation for
plotting purposes. The situation would be just like the delaunay code
which exists in a scikit but we include it in the mpl source code to avoid
the external dependency.
Once it is in mpl it is available for other projects to use if they wish,
subject to the BSD-style license. There would be a question of who is
responsible for maintaining it as I don't particularly want to spread
myself thinly on other open source projects when there are a lot of
additions to mpl that I would like to do. There would be the danger for
the other project of the reverse situation of our delaunay example, where
we have code that needs improvement but it is essentially unmaintained,
causing problems for users and embarrassment for developers.
> I have a C++ TriFinder class
> > that I could modify to work within matplotlib, and it is O(log N) so
> should
> > be faster than your version for typical use cases.
>
> What algorithm does this use? Is the code open source and/or availabel
> for other projects?
>
> I'm working on a package for working with unstructured grids in
> general, and also have a use for "what triangle is this point in" code
> for other purposes -- and I havne't found a fast, robust code for this
> yet.
>
It is code I have written recently based on the trapezoidal map algorithm
from the book 'Computational Geometry: Algorithms and Applications' by M.
de Berg et al. It currently exists only on my main linux box, but it will
be open source within mpl for others to use as mentioned above (subject to
acceptance by the mpl developers of course). It is an excellent book that
I wholeheartedly recommend to anyone with a passing interest in
computational geometry. The algorithm itself looks painful initially (as
do many of the algorithms in the book) but it reduces to a surprisingly
small amount of code.
For well-formed triangulations (i.e. no duplicate points, no zero area
triangles and no overlapping triangles) the algorithm is 'sufficiently'
robust. It is not completely robust in the sense of Shewchuk's robust
predicates, but is designed quite cleverly (or luckily) to avoid many of
the pitfalls that occur in naive point-in-triangle tests. For example, a
naive implementation of a point-in-triangle test for a point on or very
near the common edge of two adjacent triangles might return true for both
triangles (which is usually fine), or false for both (which is
catastrophic). The trapezoidal map avoids these problems by reducing the
test to a single point-line test which is therefore guaranteed to return
just one of the two triangles. It is possible to think of a situation that
causes the algorithm to fail at a triangle which has such a small area that
the slopes of two of the sides are within the machine precision of each
other, but it is also possible to use the triangle connectivity to check
for and resolve this problem. I haven't done so yet and need to consider
the tradeoff of effort required vs potential gain.
Someone who required guaranteed robustness could use Shewchuk's point-line
test with the algorithm. I would not do this with mpl however, as the
correctness of the point-line test depends a lot on computer architecture
and compiler flags. This would get out of date quickly and would need keen
monitoring by someone with knowledge of and interest in the area, plus
access to a lot of different computer architectures and OSes. I fail on
all of those counts!
> >> particularly as only a few days ago I committed to writing a triangular
> grid
> >> interpolator for quad grids
>
> what is a triangular interpolator for quad grids? sounds useful, too.
That was poor English from me. I meant interpolating from a triangular
grid *to* a quad grid, typically to make use of the wide range of quad grid
plotting functions like contour, pcolor, etc.
Ian

On Thu, Nov 15, 2012 at 3:25 PM, Chris Barker <chr...@no...> wrote:
> On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas <ian...@gm...> wrote:
>
>> I think the code used to determine which triangle contains a certain point
>> should be factored out into its own TriFinder class,
>
> +1 -- this is a generally useful feature. In fact, it would be nice if
> a lot of this were in a pacakge that deals with triangular meshes,
> apart from MPL altogether (a scikit maybe?)
>
>> I have a C++ TriFinder class
>> that I could modify to work within matplotlib, and it is O(log N) so should
>> be faster than your version for typical use cases.
>
> What algorithm does this use? Is the code open source and/or availabel
> for other projects?
I'm pretty sure there is an O(log n) algorithm in the Numerical
Recipes book. It requires you to construct the triangulation in a
specific way (this allows one to set up a tree data structure of
triangles nicely). There may be others that I am not aware of though.
>
> I'm working on a package for working with unstructured grids in
> general, and also have a use for "what triangle is this point in" code
> for other purposes -- and I havne't found a fast, robust code for this
> yet.
>
>>> particularly as only a few days ago I committed to writing a triangular grid
>>> interpolator for quad grids
>
> what is a triangular interpolator for quad grids? sounds useful, too.
>
> -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...
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

OK so it seems that integrating any efficient OpenGL rendering code in
matplotlib as a backend is much more complicated than what I thought.
> I'm guessing with galry, you push the user-coordinates to the graphics
> card, then as the user is interacting, you're changing the transforms
> and re-rendering, but don't need to push the vertex data itself over
> and over again, and with with shaders, you could do arbitrary
> transforms. hence high performance.
You're absolutely right, that's the way high performance is achieved in
Galry. In fact, the low-level interface provides a way to write custom
shaders to implement really anything (interactive transformations or any
rendering effect). Whereas it is possible to push data on the GPU at any
time, the most efficient way of rendering stuff in Galry is to push
everything at the beginning, and then only update uniform shader variables
to implement transforms and dynamic effects.
That does not seem very compatible with the way backends appear to work
then. I fear that in order to have an efficient GL backend, either this
backend system would need to be updated so that it can be directly
connected to transformation events, or one would need to get around the
backend system.
Anyway, it looks like the difficulty would come more from the matplotlib
backend system than the OpenGL part (by the way, your rendering demos are
really cool Nicolas!). It would be great if a GSoC student could work on
this, and I would be happy to help if necessary. In the meantime, I might
write sometime an extremely basic high-level matplotlib-like interface for
Galry, with support in particular for scatter plots, continuous-time
signals, textures, maybe other plot types if anyone asks. It may be useful
until a fully working GL backend becomes available.
Cyrille
2012年11月15日 Nicolas Rougier <Nic...@in...>
>
>
> Yep, I'm still developing some OpenGL technics to provide both nice and
> fast rendering and I hope to be able to help the writing of a GL backend
> for matplotlib next summer (provided we get a GSoC student for the project).
>
> So far, my main concern is that for efficient rendering using OpenGL, you
> need to consider that drawing means to create objects on the graphic card
> (line, curve, image, points, etc) that can be later manipulated
> (scaling/rotating/coloring/properties change, etc.). From what I remember
> in my early attempts at writing an OpenGL backend, I did not find the
> proper way to enforce such framework. Said differently, the backend is
> supposed to implement drawing operations while I would need to know if the
> drawing operations actually relates to something that is already on the
> graphic card or not. I'm not sure I'm very clear but I can develop the
> point if necessary. Having read the post by Michael (
> http://mdboom.github.com/blog/2012/08/06/matplotlib-client-side/) on
> client-side rendering, I think the proposed three-way split might be a
> solution but I do not know how advanced are the ideas.
>
> To date, I've been working on different things:
>
> Text/font : http://code.google.com/p/freetype-gl/ (c code)
> Stroke/dash/paths: http://code.google.com/p/gl-agg/ (python)
> Images: http://code.google.com/p/glumpy/ (python)
>
> If you want to get a feel of how nice and fast rendering could be, have a
> look at 'demo-lines.py' from the gl-agg repository (and play with mouse).
> From these experiments, I think it is possible to achieve AGG quality using
> OpenGL. What is really exciting is the perspective of having a opengl/webgl
> backend that could be used with ipython (there has been a recent post on
> ipython list that show such integration for a molecule viewer).
>
>
> Anyway, you're more than welcome to contribute to glumpy, but in the long
> run, I hope it will disappear in favor of a matplolib GL backend.
>
>
>
> Nicolas
>
>
>
>
>
>
> On Nov 15, 2012, at 22:03 , Benjamin Root wrote:
>
> >
> >
> > On Thu, Nov 15, 2012 at 2:24 PM, Cyrille Rossant <
> cyr...@gm...> wrote:
> > Hi all,
> >
> > I am developing a high-performance interactive visualization package in
> Python based on PyOpenGL (http://rossant.github.com/galry/). It is
> primarily meant to be used as a framework for developing complex
> interactive GUIs (in QT) that deal with very large amounts of data (tens of
> millions of points). But it may also be used, like matplotlib, as a
> high-level interactive library to plot and visualize data.
> >
> > The low-level interface is mostly done at this point (the code is still
> in an experimental stage though), and I'm now focusing on my current
> research project which is to write a scientific GUI based on this
> interface. However, I think people (including myself!) may be interested in
> a matplotlib-like high-level interface. I was first thinking about writing
> such an interface from scratch, by implementing a very small fraction of
> the matplotlib interface (basic commands like figure(), plot(), subplot(),
> show(), etc.). One could then quickly visualize huge datasets with the same
> commands than matplotlib.
> >
> > Another solution would be to write a matplotlib backend based on this
> library. I am not familar enough with the internals of matplotlib to know
> how complicated it could be. I may do it myself, but it would probably take
> a long time since it is currently not my highest priority. I would be glad
> if someone experienced in writing backends was interested in working on it.
> Actually I could do everything that is specific to my library, which
> already provides commands to plot points, lines, textures, etc. The canvas
> is based on QT and may be similar to what is already implemented in the QT
> backend.
> >
> > Of course, it would already be great if only the most basic plotting
> features were available in the backend. A first step could be for example
> to have a simplistic example "plot(x, sin(x))" working (with interactive
> navigation).
> >
> > I am looking forward to your feedback.
> >
> > Best,
> > Cyrille Rossant
> >
> >
> > Great to hear another person interested in bringing opengl to
> matplotlib! Another project you might be interested in collaborating with
> is Glumpy: http://code.google.com/p/glumpy/
> >
> > From my limited knowledge of OpenGL, what my vision is that any of the
> existing backends have support for an OpenGL object, so we just need to be
> able to instantiate the opengl object in any figure object, and know how to
> send it the appropriate commands and data. So, it is not exactly a
> backend, more of a "middling". Anyway, I think the dev at Glumpy would be
> happy to have help, and probably have much more developed ideas on how to
> integrate with matplotlib.
> >
> > Cheers!
> > Ben Root
> >
> >
> ------------------------------------------------------------------------------
> > Monitor your physical, virtual and cloud infrastructure from a single
> > web console. Get in-depth insight into apps, servers, databases, vmware,
> > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > Pricing starts from 795ドル for 25 servers or applications!
> >
> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Yep, I'm still developing some OpenGL technics to provide both nice and fast rendering and I hope to be able to help the writing of a GL backend for matplotlib next summer (provided we get a GSoC student for the project).
So far, my main concern is that for efficient rendering using OpenGL, you need to consider that drawing means to create objects on the graphic card (line, curve, image, points, etc) that can be later manipulated (scaling/rotating/coloring/properties change, etc.). From what I remember in my early attempts at writing an OpenGL backend, I did not find the proper way to enforce such framework. Said differently, the backend is supposed to implement drawing operations while I would need to know if the drawing operations actually relates to something that is already on the graphic card or not. I'm not sure I'm very clear but I can develop the point if necessary. Having read the post by Michael (http://mdboom.github.com/blog/2012/08/06/matplotlib-client-side/) on client-side rendering, I think the proposed three-way split might be a solution but I do not know how advanced are the ideas.
To date, I've been working on different things:
Text/font : http://code.google.com/p/freetype-gl/ (c code)
Stroke/dash/paths: http://code.google.com/p/gl-agg/ (python)
Images: http://code.google.com/p/glumpy/ (python)
If you want to get a feel of how nice and fast rendering could be, have a look at 'demo-lines.py' from the gl-agg repository (and play with mouse). From these experiments, I think it is possible to achieve AGG quality using OpenGL. What is really exciting is the perspective of having a opengl/webgl backend that could be used with ipython (there has been a recent post on ipython list that show such integration for a molecule viewer).
Anyway, you're more than welcome to contribute to glumpy, but in the long run, I hope it will disappear in favor of a matplolib GL backend.
 
Nicolas
On Nov 15, 2012, at 22:03 , Benjamin Root wrote:
> 
> 
> On Thu, Nov 15, 2012 at 2:24 PM, Cyrille Rossant <cyr...@gm...> wrote:
> Hi all,
> 
> I am developing a high-performance interactive visualization package in Python based on PyOpenGL (http://rossant.github.com/galry/). It is primarily meant to be used as a framework for developing complex interactive GUIs (in QT) that deal with very large amounts of data (tens of millions of points). But it may also be used, like matplotlib, as a high-level interactive library to plot and visualize data.
> 
> The low-level interface is mostly done at this point (the code is still in an experimental stage though), and I'm now focusing on my current research project which is to write a scientific GUI based on this interface. However, I think people (including myself!) may be interested in a matplotlib-like high-level interface. I was first thinking about writing such an interface from scratch, by implementing a very small fraction of the matplotlib interface (basic commands like figure(), plot(), subplot(), show(), etc.). One could then quickly visualize huge datasets with the same commands than matplotlib.
> 
> Another solution would be to write a matplotlib backend based on this library. I am not familar enough with the internals of matplotlib to know how complicated it could be. I may do it myself, but it would probably take a long time since it is currently not my highest priority. I would be glad if someone experienced in writing backends was interested in working on it. Actually I could do everything that is specific to my library, which already provides commands to plot points, lines, textures, etc. The canvas is based on QT and may be similar to what is already implemented in the QT backend.
> 
> Of course, it would already be great if only the most basic plotting features were available in the backend. A first step could be for example to have a simplistic example "plot(x, sin(x))" working (with interactive navigation).
> 
> I am looking forward to your feedback.
> 
> Best,
> Cyrille Rossant
> 
> 
> Great to hear another person interested in bringing opengl to matplotlib! Another project you might be interested in collaborating with is Glumpy: http://code.google.com/p/glumpy/
> 
> From my limited knowledge of OpenGL, what my vision is that any of the existing backends have support for an OpenGL object, so we just need to be able to instantiate the opengl object in any figure object, and know how to send it the appropriate commands and data. So, it is not exactly a backend, more of a "middling". Anyway, I think the dev at Glumpy would be happy to have help, and probably have much more developed ideas on how to integrate with matplotlib.
> 
> Cheers!
> Ben Root
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas <ian...@gm...> wrote:
> I think the code used to determine which triangle contains a certain point
> should be factored out into its own TriFinder class,
+1 -- this is a generally useful feature. In fact, it would be nice if
a lot of this were in a pacakge that deals with triangular meshes,
apart from MPL altogether (a scikit maybe?)
> I have a C++ TriFinder class
> that I could modify to work within matplotlib, and it is O(log N) so should
> be faster than your version for typical use cases.
What algorithm does this use? Is the code open source and/or availabel
for other projects?
I'm working on a package for working with unstructured grids in
general, and also have a use for "what triangle is this point in" code
for other purposes -- and I havne't found a fast, robust code for this
yet.
>> particularly as only a few days ago I committed to writing a triangular grid
>> interpolator for quad grids
what is a triangular interpolator for quad grids? sounds useful, too.
-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...