matplotlib-devel — matplotlib developers

[matplotlib-devel] Add `streamplot` function

[Tony Yu <ts...@gm...>]

I just submitted a pull request to add a `streamplot` function to plot the
streamlines of a vector field. This implementation is a modified version of
the streamplot function posted to the list by Tom Flannagan [1].

This PR isn't complete, but I wanted to submit it in order to get comments.
In particular:

* I haven't added the pyplot function, only the axes method. It looks like
the pyplot function should be generated by some boiler plate code.

* I'm not sure what the docstring conventions are (the code isn't terribly
consistent), so I just (more-or-less) followed the numpy docs.

* Some parameter that probably should be adjustable aren't at the moment
(e.g. max streamline length, some arrow properties).

* I left the original copyright from Tom's implementation, but I don't know
if the BSD license has anything to say about that.

I'm not totally familiar with the matplotlib architecture so I'm probably
forgetting a number of things. Feedback appreciated.

-Tony

[1]
http://www.mail-archive.com/mat...@li.../msg20208.html

[matplotlib-devel] Caption in Plot Directive

[Skipper S. <jss...@gm...>]

Moving this to matplotlib-devel

On Thu, Jan 5, 2012 at 1:17 PM, Skipper Seabold <jss...@gm...> wrote:
> Is this information incorrect?
>
> http://matplotlib.sourceforge.net/devel/documenting_mpl.html#module-matplotlib.sphinxext.plot_directive
>
> This line seems to preclude ever getting to the below code to process
> the caption.
>
> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/sphinxext/plot_directive.py#L601
>
> I think the proper fix is to make :caption: an option.

I implemented :caption: as an option [1], but this is at odds with the
original figure directive [2]. AFAICT either the check for content and
arguments has to be removed and all content after a filename is given
is assumed to be a caption, or caption has to become an option.

Skipper

[1] https://github.com/jseabold/matplotlib/commit/2f003e296a0c37bcbf6687702ddfd34ac12235b4
[2] http://docutils.sourceforge.net/docs/ref/rst/directives.html#figure

Re: [matplotlib-devel] RectangleSelector

[Michael D. <md...@st...>]

On 01/05/2012 02:22 AM, Benjamin Root wrote:
>
> >
> >
>
> I don't have an opinion on this yet, but I do want to note that if 
> this change were applied, then the lasso selector should probably also 
> be changed in order to be consistent.

I believe the lasso selector already does this (determined 
experimentally at least) -- this brings the RectangleSelector widget in 
line with that.

Mike

Re: [matplotlib-devel] RectangleSelector

[Arnaud G. <ar...@os...>]

Done.

Le jeudi 05 janvier 2012 à 07:46 -0500, Michael Droettboom a écrit :
> This is a great fix.  Would you mind submitting it as a github pull 
> request so we can review it there?
> 
> Mike
> 
> On 01/05/2012 01:20 AM, Arnaud Gardelein wrote:
> > In my configuration, when button is released out of the axes,
> > RectangleSelector does not catch the release-button event. The rectangle
> > patch is then left on the Axe. I found more convenient for my
> > application (oscopy, see oscopy.org) to catch the event even if out of
> > axes and limit to the boundaries of the axes. Maybe this can be of any
> > use to somebody else.
> >
> > *** widgets.py	2012-01-05 07:03:23.723656417 +0100
> > --- widgets2.py	2012-01-05 07:04:29.351981851 +0100
> > ***************
> > *** 1242,1247 ****
> > --- 1242,1262 ----
> >                return event.inaxes!= self.ax
> >
> >            # If a button was pressed, check if the release-button is the
> > +         # same. If event is out of axis, limit the data coordinates to
> > axes
> > +         # boundaries.
> > +         if event.button == self.eventpress.button and event.inaxes !=
> > self.ax:
> > +             (xdata, ydata) =
> > self.ax.transData.inverted().transform_point((event.x, event.y))
> > +             xlim = self.ax.get_xlim()
> > +             ylim = self.ax.get_ylim()
> > +             if xdata<  xlim[0]: xdata = xlim[0]
> > +             if xdata>  xlim[1]: xdata = xlim[1]
> > +             if ydata<  ylim[0]: ydata = ylim[0]
> > +             if ydata>  ylim[1]: ydata = ylim[1]
> > +             event.xdata = xdata
> > +             event.ydata = ydata
> > +             return False
> > +
> > +         # If a button was pressed, check if the release-button is the
> >            # same.
> >            return  (event.inaxes!=self.ax or
> >                     event.button != self.eventpress.button)
> >
> > Arnaud.
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual
> > desktops for less than the cost of PCs and save 60% on VDI infrastructure
> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Michael D. <md...@st...>]

I think I've discovered the root of this problem.

A change was made during the 1.1.x cycle to tell Agg that we're giving 
it premultiplied alpha in the image data (see commit 1dac36d829).  This 
made displaying images loaded from files that had an alpha channel work 
correctly and made it consistent with the PDF and SVG backends.  
Unfortunately, that seems to have broken things for colormapped images 
where the colormapping does not generate premultiplied alpha.  (That 
weird coloring thing was due to Agg "clipping" the r, g, b values to be 
<= a, which it does when it's expecting pre-multiplied alpha).

I believe the fix is to premultiply the image right after colormapping 
it.  I've submitted a pull request against efiring's alpha_colormap 
branch that does this.  This is just a quick proof-of-concept fix -- no 
guarantees that it's complete and doesn't have any unintended consequences.

Note that we can't just do the premultiplication in the color mapping 
class itself, since other things in the Agg backend (such as line 
drawing) do not expect premultiplied alpha -- premultiplication should 
only be applied to images.  The side benefit is that this change also 
makes the output of the PDF and SVG backends agree with the Agg backend.

Mike

On 01/04/2012 04:14 PM, Tony Yu wrote:
>  On Tue, Jan 3, 2012 at 1:10 AM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
>     On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>
>
>         On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing
>         <ef...@ha... <mailto:ef...@ha...>
>         <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>
>            On 12/30/2011 01:57 PM, Paul Ivanov wrote:
>
>                Eric Firing, on 2011-12-27 15:31,  wrote:
>
>                    It looks like this is something I can fix by modifying
>                    ListedColormap.
>                    It is discarding the alpha values, and I don't
>         think there
>                    is any reason
>                    it needs to do so.
>
>
>                One of my first attempts at a contribution to
>         matplotlib three
>                years ago was related to this. It was in reply to a similar
>                question on list, and I wrote a patch, but never saw it
>         through
>                to inclusion because it wasn't something I needed.
>
>         http://www.mail-archive.com/__matplotlib-users@lists.__sourceforge.net/msg09216.html
>
>
>         <http://www.mail-archive.com/mat...@li.../msg09216.html>
>
>                I think it's a helpful starting point, as I include a
>         discussion
>                on the limitation of mpl colormaps there.
>
>
>            I'm switching this to the devel list.
>
>            Please try
>         https://github.com/efiring/__matplotlib/tree/colormap_alpha
>
>         <https://github.com/efiring/matplotlib/tree/colormap_alpha>
>            which has changes similar to yours so that alpha is fully
>         changeable
>            in colormaps.
>
>            I think this is going to be OK as far as the colormap end
>         of things
>            is concerned, but it turns up a new problem related to alpha in
>            images, and reminds us of an old problem with alpha in agg, at
>            least.  The problems are illustrated in the attached
>         modification of
>            the custom_cmap.py example.  I added a fourth panel for testing
>            alpha.  Look at the comments on the code for that panel,
>         and try
>            switching between pcolormesh and imshow.  Pcolormesh
>         basically works
>            as expected, except for the prominent artifacts on patch
>         boundaries
>            (visible also in the colorbar for that panel).  These boundary
>            artifacts are the old problem. The new problem is that
>         imshow with
>            alpha in the colormap is completely wonky with a white
>         background,
>            but looks more normal with a black background--which is not
>         so good
>            if what you really want is a white background showing
>         through the
>            transparency.
>
>            Eric
>
>
>         This is great! I had hacked together a custom colormap class and
>         overrode its __call__ method to get a similar effect. This
>         solution is
>         much more elegant and general.
>
>         As for the imshow issue, it seems to be an issue with the
>         "nearest"
>         interpolation method. The example copied below shows the
>         result for
>         three different interpolation methods. The weird behavior only
>         occurs
>         when interpolation is set to 'nearest' (I checked all other
>         interpolation methods, not just the 3 below). What's really
>         strange is
>         that `interpolation='none'` gives the expected result, but in
>         theory,
>         'none' maps to the same interpolation function as 'nearest'. A
>         quick
>         scan of matplotlib.image suggests that 'none' and 'nearest'
>         share the
>         same code path, but I'm obviously missing something.
>
>
>     It looks to me like 'none' is going through _draw_unsampled_image
>     instead of the path that all the other interpolations, including
>     'nearest' go through.  I think that JJ put in this unsampled
>     functionality about two years ago.  I've never dug into the guts
>     of image operations and rendering, so I don't even understand what
>     sort of "sampling" is referred to here.
>
>     Eric
>
>
> Well, that's embarrassing: Apparently I searched for 'none' with 
> single quotes, but not double quotes.
>
> Unfortunately, I can't figure out the issue, but while debugging, I 
> noticed that constant alpha values have the same issue. For example, 
> if you replace the alpha spec in the custom colormap with:
>
>      'alpha': ((0.0, 0.7, 0.7),
>                   (1.0, 0.7, 0.7))}
>
> then you see the same issue. If, however, you set alpha to 1 in the 
> colormap, but set `alpha=1` in `imshow`, then everything works as 
> expected.
>
> It almost seems like it maybe an overflow issue. As you gradually 
> decrease the alpha value (in the colormap, not in imshow), the whiter 
> colors start to get weird, then successively darker colors get 
> weird---you can check this with the script copied below.
>
> In any case, I think the problem is in C-code, which I'm not really 
> equipped to debug. Hopefully, someone else can track this down.
>
> -Tony
>
>
> import numpy as np
> import matplotlib.pyplot as plt
> from matplotlib.colors import LinearSegmentedColormap
>
>
> cdict = {'red':  ((0.0, 0.0, 0.0),
>                   (0.5, 0.8, 1.0),
>                   (1.0, 0.4, 1.0)),
>
>         'green': ((0.0, 0.0, 0.0),
>                   (0.5, 0.9, 0.9),
>                   (1.0, 0.0, 0.0)),
>
>         'blue':  ((0.0, 0.0, 0.4),
>                   (0.5, 1.0, 0.8),
>                   (1.0, 0.0, 0.0))}
>
> w = 10
> y = np.linspace(0, 2*np.pi, w+1)
> Z = np.tile(y, (w+1, 1))
>
> alpha_values = (1, 0.9, 0.7, 0.5)
>
> f, axes = plt.subplots(ncols=len(alpha_values))
> for i, (ax, alpha) in enumerate(zip(axes, alpha_values)):
>     cdict = cdict.copy()
>     cdict['alpha'] = [(0.0, alpha, alpha), (1.0, alpha, alpha)]
>     cmap = LinearSegmentedColormap('BlueRedAlpha%i' % i, cdict)
>     im = ax.imshow(Z, interpolation='nearest', cmap=cmap)
>     ax.set_title('alpha = %g' % alpha)
>
> plt.show()
>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib-1.1.0.win32-py2.7.exe crashes during install

[Dejas N. <dej...@gm...>]

Hi,

I downloaded matplotlib-1.1.0.win32-py2.7.exe and tried to run in on
Windows 7.  During the install, just after clicking "Next" on the "Ready to
install" screen the program freezes and I get a message saying
"matplotlib-1.1.0.win32-py2.7.exe has stopped working".

Please advise.

Thanks.

Re: [matplotlib-devel] RectangleSelector

[Michael D. <md...@st...>]

This is a great fix.  Would you mind submitting it as a github pull 
request so we can review it there?

Mike

On 01/05/2012 01:20 AM, Arnaud Gardelein wrote:
> In my configuration, when button is released out of the axes,
> RectangleSelector does not catch the release-button event. The rectangle
> patch is then left on the Axe. I found more convenient for my
> application (oscopy, see oscopy.org) to catch the event even if out of
> axes and limit to the boundaries of the axes. Maybe this can be of any
> use to somebody else.
>
> *** widgets.py	2012-01-05 07:03:23.723656417 +0100
> --- widgets2.py	2012-01-05 07:04:29.351981851 +0100
> ***************
> *** 1242,1247 ****
> --- 1242,1262 ----
>                return event.inaxes!= self.ax
>
>            # If a button was pressed, check if the release-button is the
> +         # same. If event is out of axis, limit the data coordinates to
> axes
> +         # boundaries.
> +         if event.button == self.eventpress.button and event.inaxes !=
> self.ax:
> +             (xdata, ydata) =
> self.ax.transData.inverted().transform_point((event.x, event.y))
> +             xlim = self.ax.get_xlim()
> +             ylim = self.ax.get_ylim()
> +             if xdata<  xlim[0]: xdata = xlim[0]
> +             if xdata>  xlim[1]: xdata = xlim[1]
> +             if ydata<  ylim[0]: ydata = ylim[0]
> +             if ydata>  ylim[1]: ydata = ylim[1]
> +             event.xdata = xdata
> +             event.ydata = ydata
> +             return False
> +
> +         # If a button was pressed, check if the release-button is the
>            # same.
>            return  (event.inaxes!=self.ax or
>                     event.button != self.eventpress.button)
>
> Arnaud.
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RectangleSelector

[Benjamin R. <ben...@ou...>]

On Thursday, January 5, 2012, Arnaud Gardelein <ar...@os...> wrote:
> In my configuration, when button is released out of the axes,
> RectangleSelector does not catch the release-button event. The rectangle
> patch is then left on the Axe. I found more convenient for my
> application (oscopy, see oscopy.org) to catch the event even if out of
> axes and limit to the boundaries of the axes. Maybe this can be of any
> use to somebody else.
>
> *** widgets.py  2012-01-05 07:03:23.723656417 +0100
> --- widgets2.py 2012-01-05 07:04:29.351981851 +0100
> ***************
> *** 1242,1247 ****
> --- 1242,1262 ----
>              return event.inaxes!= self.ax
>
>          # If a button was pressed, check if the release-button is the
> +         # same. If event is out of axis, limit the data coordinates to
> axes
> +         # boundaries.
> +         if event.button == self.eventpress.button and event.inaxes !=
> self.ax:
> +             (xdata, ydata) =
> self.ax.transData.inverted().transform_point((event.x, event.y))
> +             xlim = self.ax.get_xlim()
> +             ylim = self.ax.get_ylim()
> +             if xdata < xlim[0]: xdata = xlim[0]
> +             if xdata > xlim[1]: xdata = xlim[1]
> +             if ydata < ylim[0]: ydata = ylim[0]
> +             if ydata > ylim[1]: ydata = ylim[1]
> +             event.xdata = xdata
> +             event.ydata = ydata
> +             return False
> +
> +         # If a button was pressed, check if the release-button is the
>          # same.
>          return  (event.inaxes!=self.ax or
>                   event.button != self.eventpress.button)
>
> Arnaud.
>
>

I don't have an opinion on this yet, but I do want to note that if this
change were applied, then the lasso selector should probably also be
changed in order to be consistent.

Ben Root

[matplotlib-devel] RectangleSelector

[Arnaud G. <ar...@os...>]

In my configuration, when button is released out of the axes,
RectangleSelector does not catch the release-button event. The rectangle
patch is then left on the Axe. I found more convenient for my
application (oscopy, see oscopy.org) to catch the event even if out of
axes and limit to the boundaries of the axes. Maybe this can be of any
use to somebody else.

*** widgets.py	2012-01-05 07:03:23.723656417 +0100
--- widgets2.py	2012-01-05 07:04:29.351981851 +0100
***************
*** 1242,1247 ****
--- 1242,1262 ----
              return event.inaxes!= self.ax
  
          # If a button was pressed, check if the release-button is the
+         # same. If event is out of axis, limit the data coordinates to
axes
+         # boundaries.
+         if event.button == self.eventpress.button and event.inaxes !=
self.ax:
+             (xdata, ydata) =
self.ax.transData.inverted().transform_point((event.x, event.y))
+             xlim = self.ax.get_xlim()
+             ylim = self.ax.get_ylim()
+             if xdata < xlim[0]: xdata = xlim[0]
+             if xdata > xlim[1]: xdata = xlim[1]
+             if ydata < ylim[0]: ydata = ylim[0]
+             if ydata > ylim[1]: ydata = ylim[1]
+             event.xdata = xdata
+             event.ydata = ydata
+             return False
+ 
+         # If a button was pressed, check if the release-button is the
          # same.
          return  (event.inaxes!=self.ax or
                   event.button != self.eventpress.button)

Arnaud.

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Tony Yu <ts...@gm...>]

 On Tue, Jan 3, 2012 at 1:10 AM, Eric Firing <ef...@ha...> wrote:

> On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>>
>>
>> On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>>    On 12/30/2011 01:57 PM, Paul Ivanov wrote:
>>
>>        Eric Firing, on 2011-12-27 15:31,  wrote:
>>
>>            It looks like this is something I can fix by modifying
>>            ListedColormap.
>>            It is discarding the alpha values, and I don't think there
>>            is any reason
>>            it needs to do so.
>>
>>
>>        One of my first attempts at a contribution to matplotlib three
>>        years ago was related to this. It was in reply to a similar
>>        question on list, and I wrote a patch, but never saw it through
>>        to inclusion because it wasn't something I needed.
>>
>>        http://www.mail-archive.com/__**matplotlib-users@lists.__**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/__matplotlib-users@lists.__sourceforge.net/msg09216.html>
>>
>>        <http://www.mail-archive.com/**matplotlib-users@lists.**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/mat...@li.../msg09216.html>
>> >
>>
>>        I think it's a helpful starting point, as I include a discussion
>>        on the limitation of mpl colormaps there.
>>
>>
>>    I'm switching this to the devel list.
>>
>>    Please try
>>    https://github.com/efiring/__**matplotlib/tree/colormap_alpha<https://github.com/efiring/__matplotlib/tree/colormap_alpha>
>>
>>    <https://github.com/efiring/**matplotlib/tree/colormap_alpha<https://github.com/efiring/matplotlib/tree/colormap_alpha>
>> **>
>>    which has changes similar to yours so that alpha is fully changeable
>>    in colormaps.
>>
>>    I think this is going to be OK as far as the colormap end of things
>>    is concerned, but it turns up a new problem related to alpha in
>>    images, and reminds us of an old problem with alpha in agg, at
>>    least.  The problems are illustrated in the attached modification of
>>    the custom_cmap.py example.  I added a fourth panel for testing
>>    alpha.  Look at the comments on the code for that panel, and try
>>    switching between pcolormesh and imshow.  Pcolormesh basically works
>>    as expected, except for the prominent artifacts on patch boundaries
>>    (visible also in the colorbar for that panel).  These boundary
>>    artifacts are the old problem. The new problem is that imshow with
>>    alpha in the colormap is completely wonky with a white background,
>>    but looks more normal with a black background--which is not so good
>>    if what you really want is a white background showing through the
>>    transparency.
>>
>>    Eric
>>
>>
>> This is great! I had hacked together a custom colormap class and
>> overrode its __call__ method to get a similar effect. This solution is
>> much more elegant and general.
>>
>> As for the imshow issue, it seems to be an issue with the "nearest"
>> interpolation method. The example copied below shows the result for
>> three different interpolation methods. The weird behavior only occurs
>> when interpolation is set to 'nearest' (I checked all other
>> interpolation methods, not just the 3 below). What's really strange is
>> that `interpolation='none'` gives the expected result, but in theory,
>> 'none' maps to the same interpolation function as 'nearest'. A quick
>> scan of matplotlib.image suggests that 'none' and 'nearest' share the
>> same code path, but I'm obviously missing something.
>>
>
> It looks to me like 'none' is going through _draw_unsampled_image instead
> of the path that all the other interpolations, including 'nearest' go
> through.  I think that JJ put in this unsampled functionality about two
> years ago.  I've never dug into the guts of image operations and rendering,
> so I don't even understand what sort of "sampling" is referred to here.
>
> Eric
>

Well, that's embarrassing: Apparently I searched for 'none' with single
quotes, but not double quotes.

Unfortunately, I can't figure out the issue, but while debugging, I noticed
that constant alpha values have the same issue. For example, if you replace
the alpha spec in the custom colormap with:

     'alpha': ((0.0, 0.7, 0.7),
                  (1.0, 0.7, 0.7))}

then you see the same issue. If, however, you set alpha to 1 in the
colormap, but set `alpha=1` in `imshow`, then everything works as expected.

It almost seems like it maybe an overflow issue. As you gradually decrease
the alpha value (in the colormap, not in imshow), the whiter colors start
to get weird, then successively darker colors get weird---you can check
this with the script copied below.

In any case, I think the problem is in C-code, which I'm not really
equipped to debug. Hopefully, someone else can track this down.

-Tony


import numpy as np
import matplotlib.pyplot as plt
from matplotlib.colors import LinearSegmentedColormap


cdict = {'red':  ((0.0, 0.0, 0.0),
                  (0.5, 0.8, 1.0),
                  (1.0, 0.4, 1.0)),

        'green': ((0.0, 0.0, 0.0),
                  (0.5, 0.9, 0.9),
                  (1.0, 0.0, 0.0)),

        'blue':  ((0.0, 0.0, 0.4),
                  (0.5, 1.0, 0.8),
                  (1.0, 0.0, 0.0))}

w = 10
y = np.linspace(0, 2*np.pi, w+1)
Z = np.tile(y, (w+1, 1))

alpha_values = (1, 0.9, 0.7, 0.5)

f, axes = plt.subplots(ncols=len(alpha_values))
for i, (ax, alpha) in enumerate(zip(axes, alpha_values)):
    cdict = cdict.copy()
    cdict['alpha'] = [(0.0, alpha, alpha), (1.0, alpha, alpha)]
    cmap = LinearSegmentedColormap('BlueRedAlpha%i' % i, cdict)
    im = ax.imshow(Z, interpolation='nearest', cmap=cmap)
    ax.set_title('alpha = %g' % alpha)

plt.show()

Re: [matplotlib-devel] Merging v1.1.x to master?

[Benjamin R. <ben...@ou...>]

On Tue, Jan 3, 2012 at 10:12 AM, Michael Droettboom <md...@st...> wrote:

> I've been away on vacation -- just to confirm, it looks like Benjamin
> Root (@WeatherGod) has already got around to doing this?
>
> Mike
>
>
No, I think it was done before me.  My merge only brought in a one-line fix.

Ben Root

Re: [matplotlib-devel] Merging v1.1.x to master?

[Michael D. <md...@st...>]

I've been away on vacation -- just to confirm, it looks like Benjamin 
Root (@WeatherGod) has already got around to doing this?

Mike

On 12/27/2011 03:07 PM, Jouni K. Seppänen wrote:
> I had some time to work on matplotlib, and created pull request #633 to
> fix a bug reported recently. I branched off v1.1.x since the fix is
> small and self-contained, and thought I'd create a different branch for
> master, where the relevant code has changed a little. (What should the
> process be in this kind of cases?)
>
> However, it seems that v1.1.x has diverged from master:
>
> commit 2da9d8fb5d087eaeb31c0af88141aafaf0716e9c
> Merge: 3c3c466 585606f
> Author: Eric Firing<ef...@ha...>
> Date:   Wed Dec 14 10:01:53 2011 -0800
>
>      Merge pull request #627 from efiring/quiver_angle
>
>      Quiver: copy input angles array to avoid side effects; fixes issue #625
>
> commit 3c3c466564cba3d80f928a46857e54738787779b
> Merge: 96caca8 fb52b96
> Author: Michael Droettboom<md...@gm...>
> Date:   Wed Dec 14 06:10:26 2011 -0800
>
>      Merge pull request #586 from mdboom/numpy-version-13
>
>      Numpy version 1.4
>
> commit 585606f7bd79b93cbaa9d538cbf537c82cb9a4a6
> Author: Eric Firing<ef...@ha...>
> Date:   Tue Dec 13 07:53:54 2011 -1000
>
>      Quiver: copy input angles array to avoid side effects; fixes issue #625
>
> commit fb52b961a596c41fa2a1bb2dd85d7078f2ad39de
> Author: Michael Droettboom<md...@gm...>
> Date:   Mon Nov 14 14:42:28 2011 -0500
>
>      Put the minimum required version of Numpy in one place.
>
> commit bf73b9088e0ce5e2dfcc5b2cac9a4f20515ed9f2
> Author: Michael Droettboom<md...@gm...>
> Date:   Mon Nov 14 08:31:34 2011 -0500
>
>      Update checks and documentation to refer to Numpy 1.4 as the minimum Numpy version.
>
> I presume all of these changes are wanted on master, but the branch
> doesn't merge cleanly. It would probably be best if the author of each
> change did the merging into master, since they know best how to resolve
> any merge conflicts. I can make a suggested merge as a pull request, but
> it would be best if Eric and Michael reviewed it.
>

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Eric F. <ef...@ha...>]

On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>
> On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 12/30/2011 01:57 PM, Paul Ivanov wrote:
>
>         Eric Firing, on 2011-12-27 15:31,  wrote:
>
>             It looks like this is something I can fix by modifying
>             ListedColormap.
>             It is discarding the alpha values, and I don't think there
>             is any reason
>             it needs to do so.
>
>
>         One of my first attempts at a contribution to matplotlib three
>         years ago was related to this. It was in reply to a similar
>         question on list, and I wrote a patch, but never saw it through
>         to inclusion because it wasn't something I needed.
>
>         http://www.mail-archive.com/__matplotlib-users@lists.__sourceforge.net/msg09216.html
>         <http://www.mail-archive.com/mat...@li.../msg09216.html>
>
>         I think it's a helpful starting point, as I include a discussion
>         on the limitation of mpl colormaps there.
>
>
>     I'm switching this to the devel list.
>
>     Please try
>     https://github.com/efiring/__matplotlib/tree/colormap_alpha
>     <https://github.com/efiring/matplotlib/tree/colormap_alpha>
>     which has changes similar to yours so that alpha is fully changeable
>     in colormaps.
>
>     I think this is going to be OK as far as the colormap end of things
>     is concerned, but it turns up a new problem related to alpha in
>     images, and reminds us of an old problem with alpha in agg, at
>     least.  The problems are illustrated in the attached modification of
>     the custom_cmap.py example.  I added a fourth panel for testing
>     alpha.  Look at the comments on the code for that panel, and try
>     switching between pcolormesh and imshow.  Pcolormesh basically works
>     as expected, except for the prominent artifacts on patch boundaries
>     (visible also in the colorbar for that panel).  These boundary
>     artifacts are the old problem. The new problem is that imshow with
>     alpha in the colormap is completely wonky with a white background,
>     but looks more normal with a black background--which is not so good
>     if what you really want is a white background showing through the
>     transparency.
>
>     Eric
>
>
> This is great! I had hacked together a custom colormap class and
> overrode its __call__ method to get a similar effect. This solution is
> much more elegant and general.
>
> As for the imshow issue, it seems to be an issue with the "nearest"
> interpolation method. The example copied below shows the result for
> three different interpolation methods. The weird behavior only occurs
> when interpolation is set to 'nearest' (I checked all other
> interpolation methods, not just the 3 below). What's really strange is
> that `interpolation='none'` gives the expected result, but in theory,
> 'none' maps to the same interpolation function as 'nearest'. A quick
> scan of matplotlib.image suggests that 'none' and 'nearest' share the
> same code path, but I'm obviously missing something.

It looks to me like 'none' is going through _draw_unsampled_image 
instead of the path that all the other interpolations, including 
'nearest' go through.  I think that JJ put in this unsampled 
functionality about two years ago.  I've never dug into the guts of 
image operations and rendering, so I don't even understand what sort of 
"sampling" is referred to here.

Eric

>
> -Tony
>
> #~~~~
> import matplotlib.pyplot as plt
>
>
> cdict = {'red':  ((0.0, 0.0, 0.0),
>                    (0.5, 0.8, 1.0),
>                    (1.0, 0.4, 1.0)),
>
> 'green': ((0.0, 0.0, 0.0),
>                    (0.5, 0.9, 0.9),
>                    (1.0, 0.0, 0.0)),
>
> 'blue':  ((0.0, 0.0, 0.4),
>                    (0.5, 1.0, 0.8),
>                    (1.0, 0.0, 0.0)),
>
> 'alpha': ((0.0, 1.0, 1.0),
>                    (0.5, 0.3, 0.3),
>                    (1.0, 1.0, 1.0))}
>
> plt.register_cmap(name='BlueRedAlpha', data=cdict)
>
>
> if __name__ == '__main__':
>      import numpy as np
>
>      w = 10
>      y = np.linspace(0, 2*np.pi, w+1)
>      Z = np.tile(y, (w+1, 1))
>
>      plt.rcParams['image.cmap'] = 'BlueRedAlpha'
>
>      f, axes = plt.subplots(ncols=3)
>      interp_method = ['none', 'bilinear', 'nearest']
>      for interp, ax in zip(interp_method, axes):
>          # Draw a line with low zorder so it will be behind the image.
>          ax.plot([0, w], [0, w], color='c', lw=20, zorder=-1)
>          ax.imshow(Z, interpolation=interp)
>          ax.set_title(interp)
>
>      plt.show()
> #~~~~

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Tony Yu <ts...@gm...>]

On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <ef...@ha...> wrote:

> On 12/30/2011 01:57 PM, Paul Ivanov wrote:
>
>> Eric Firing, on 2011-12-27 15:31,  wrote:
>>
>>> It looks like this is something I can fix by modifying ListedColormap.
>>> It is discarding the alpha values, and I don't think there is any reason
>>> it needs to do so.
>>>
>>
>> One of my first attempts at a contribution to matplotlib three
>> years ago was related to this. It was in reply to a similar
>> question on list, and I wrote a patch, but never saw it through
>> to inclusion because it wasn't something I needed.
>>
>> http://www.mail-archive.com/**matplotlib-users@lists.**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/mat...@li.../msg09216.html>
>>
>> I think it's a helpful starting point, as I include a discussion
>> on the limitation of mpl colormaps there.
>>
>
> I'm switching this to the devel list.
>
> Please try
> https://github.com/efiring/**matplotlib/tree/colormap_alpha<https://github.com/efiring/matplotlib/tree/colormap_alpha>
> which has changes similar to yours so that alpha is fully changeable in
> colormaps.
>
> I think this is going to be OK as far as the colormap end of things is
> concerned, but it turns up a new problem related to alpha in images, and
> reminds us of an old problem with alpha in agg, at least.  The problems are
> illustrated in the attached modification of the custom_cmap.py example.  I
> added a fourth panel for testing alpha.  Look at the comments on the code
> for that panel, and try switching between pcolormesh and imshow.
>  Pcolormesh basically works as expected, except for the prominent artifacts
> on patch boundaries (visible also in the colorbar for that panel).  These
> boundary artifacts are the old problem. The new problem is that imshow with
> alpha in the colormap is completely wonky with a white background, but
> looks more normal with a black background--which is not so good if what you
> really want is a white background showing through the transparency.
>
> Eric
>

This is great! I had hacked together a custom colormap class and overrode
its __call__ method to get a similar effect. This solution is much more
elegant and general.

As for the imshow issue, it seems to be an issue with the "nearest"
interpolation method. The example copied below shows the result for three
different interpolation methods. The weird behavior only occurs when
interpolation is set to 'nearest' (I checked all other interpolation
methods, not just the 3 below). What's really strange is that
`interpolation='none'` gives the expected result, but in theory, 'none'
maps to the same interpolation function as 'nearest'. A quick scan of
matplotlib.image suggests that 'none' and 'nearest' share the same code
path, but I'm obviously missing something.

-Tony

#~~~~
import matplotlib.pyplot as plt


cdict = {'red':  ((0.0, 0.0, 0.0),
                  (0.5, 0.8, 1.0),
                  (1.0, 0.4, 1.0)),

        'green': ((0.0, 0.0, 0.0),
                  (0.5, 0.9, 0.9),
                  (1.0, 0.0, 0.0)),

        'blue':  ((0.0, 0.0, 0.4),
                  (0.5, 1.0, 0.8),
                  (1.0, 0.0, 0.0)),

        'alpha': ((0.0, 1.0, 1.0),
                  (0.5, 0.3, 0.3),
                  (1.0, 1.0, 1.0))}

plt.register_cmap(name='BlueRedAlpha', data=cdict)


if __name__ == '__main__':
    import numpy as np

    w = 10
    y = np.linspace(0, 2*np.pi, w+1)
    Z = np.tile(y, (w+1, 1))

    plt.rcParams['image.cmap'] = 'BlueRedAlpha'

    f, axes = plt.subplots(ncols=3)
    interp_method = ['none', 'bilinear', 'nearest']
    for interp, ax in zip(interp_method, axes):
        # Draw a line with low zorder so it will be behind the image.
        ax.plot([0, w], [0, w], color='c', lw=20, zorder=-1)
        ax.imshow(Z, interpolation=interp)
        ax.set_title(interp)

    plt.show()
#~~~~

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Eric F. <ef...@ha...>]

On 12/30/2011 01:57 PM, Paul Ivanov wrote:
> Eric Firing, on 2011-12-27 15:31,  wrote:
>> It looks like this is something I can fix by modifying ListedColormap.
>> It is discarding the alpha values, and I don't think there is any reason
>> it needs to do so.
>
> One of my first attempts at a contribution to matplotlib three
> years ago was related to this. It was in reply to a similar
> question on list, and I wrote a patch, but never saw it through
> to inclusion because it wasn't something I needed.
>
> http://www.mail-archive.com/mat...@li.../msg09216.html
>
> I think it's a helpful starting point, as I include a discussion
> on the limitation of mpl colormaps there.

I'm switching this to the devel list.

Please try
https://github.com/efiring/matplotlib/tree/colormap_alpha
which has changes similar to yours so that alpha is fully changeable in 
colormaps.

I think this is going to be OK as far as the colormap end of things is 
concerned, but it turns up a new problem related to alpha in images, and 
reminds us of an old problem with alpha in agg, at least.  The problems 
are illustrated in the attached modification of the custom_cmap.py 
example.  I added a fourth panel for testing alpha.  Look at the 
comments on the code for that panel, and try switching between 
pcolormesh and imshow.  Pcolormesh basically works as expected, except 
for the prominent artifacts on patch boundaries (visible also in the 
colorbar for that panel).  These boundary artifacts are the old problem. 
The new problem is that imshow with alpha in the colormap is completely 
wonky with a white background, but looks more normal with a black 
background--which is not so good if what you really want is a white 
background showing through the transparency.

Eric

[matplotlib-devel] installation on AIX with XLC compiler

[Davide D. V. <dd...@uc...>]

Hi,
the more recent information on installing matplotlib on AIX with XLC 
compiler are pretty dated (5 years ago), so I'd like to let you know 
what I did to have it on my machine. This is matplotlib-v1.1.0 on 
AIX-v5.3 and xlc-v10.1

Some code is worth 1000 words, so here it is, just a couple of comments:

- Note that similar problems occurred when installing scipy: 
http://projects.scipy.org/scipy/ticket/1299

- if I understand C++ Standard (ISO/IEC 14882), section 14.6.4.2, you 
should apply my patch1 below to the mainline (trunk).

#!/bin/bash
 
 
 

cat >xlC <<-"xlC-script-fooling"
      #!/bin/bash
      echo "Davide's xlC - parameters:" $*
      tbr=""
 
 
 

       # getting rid of wrong cc_r first argument
       # note that $1 becomes $params[0]
       [ "$1" = "cc_r" ] && tbr=0
 
 
 

       # getting rid of other unwanted arguments
       params=( "$@" );
 
 
 

       for i in ${!params[*]}; do
             # you don't link to stdc++ with XL compilers
             [ "${params[$i]}" == "-lstdc++" ] && tbr="$tbr $i"
       done
 
 
 

       for i in $tbr; do
             unset params[$i]
       done

       # -qmkshrobj is to create shared objects with XLC
       set -- "-qmkshrobj ${params[@]}"

       /bin/xlC $*
xlC-script-fooling
cat xlC
chmod +x xlC

cp setup.cfg.template setup.cfg
patch setup.cfg <<-"patch0"
60c
#macosx = False
.
17c
#verbose = True
.
9c
#basedirlist = /usr
.
patch0

patch agg24/include/agg_rasterizer_cells_aa.h <<-"patch1"
499c
     template <class T> AGG_INLINE void swap_cells(T* a, T* b)
.
patch1

# Note sure why they think this should be undefined on AIX
patch src/_png.cpp <<-"patch2"
34c
#endif */
.
32c
/* #ifdef _AIX
.
patch2

export PATH=$PATH:`pwd`
export PKG_CONFIG_PATH=/contrib/freetype/2.4.8/lib/pkgconfig/
export CFLAGS="-qcpluscmt -bnoquiet -I/contrib/zlib/include/ 
-I/contrib/libpng-1.2.40/include/"

source /contrib/Modules/3.2.6/init/bash
module load python zlib libpng-1.2.40

cat setup.cfg

echo
export
echo


python setup.py build

rm xlC



Regards,
Davide Del Vento,
NCAR Computational & Information Services Laboratory
Consulting Services Software Engineer
http://www.cisl.ucar.edu/hss/csg/
SEA Chair http://sea.ucar.edu/

[matplotlib-devel] Merging v1.1.x to master?

[Jouni K. S. <jk...@ik...>]

I had some time to work on matplotlib, and created pull request #633 to
fix a bug reported recently. I branched off v1.1.x since the fix is
small and self-contained, and thought I'd create a different branch for
master, where the relevant code has changed a little. (What should the
process be in this kind of cases?)

However, it seems that v1.1.x has diverged from master:

commit 2da9d8fb5d087eaeb31c0af88141aafaf0716e9c
Merge: 3c3c466 585606f
Author: Eric Firing <ef...@ha...>
Date:   Wed Dec 14 10:01:53 2011 -0800

    Merge pull request #627 from efiring/quiver_angle
    
    Quiver: copy input angles array to avoid side effects; fixes issue #625

commit 3c3c466564cba3d80f928a46857e54738787779b
Merge: 96caca8 fb52b96
Author: Michael Droettboom <md...@gm...>
Date:   Wed Dec 14 06:10:26 2011 -0800

    Merge pull request #586 from mdboom/numpy-version-13
    
    Numpy version 1.4

commit 585606f7bd79b93cbaa9d538cbf537c82cb9a4a6
Author: Eric Firing <ef...@ha...>
Date:   Tue Dec 13 07:53:54 2011 -1000

    Quiver: copy input angles array to avoid side effects; fixes issue #625

commit fb52b961a596c41fa2a1bb2dd85d7078f2ad39de
Author: Michael Droettboom <md...@gm...>
Date:   Mon Nov 14 14:42:28 2011 -0500

    Put the minimum required version of Numpy in one place.

commit bf73b9088e0ce5e2dfcc5b2cac9a4f20515ed9f2
Author: Michael Droettboom <md...@gm...>
Date:   Mon Nov 14 08:31:34 2011 -0500

    Update checks and documentation to refer to Numpy 1.4 as the minimum Numpy version.

I presume all of these changes are wanted on master, but the branch
doesn't merge cleanly. It would probably be best if the author of each
change did the merging into master, since they know best how to resolve
any merge conflicts. I can make a suggested merge as a pull request, but
it would be best if Eric and Michael reviewed it.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

[matplotlib-devel] feature: minimalist non-interactive X backend for remote use

[Daan v. R. <da...@uc...>]

Hi mpl developers,

Over the last months I've become a great matplotlib fan.  There's one thing that I miss a lot:
- a non-interactive X backend
that is fast to use remotely.

The GTK and TK backends have too much overhead for remote use, they're pretty unresponsive.  The non-interactive backends all output to files.

For analyzing data that is on a remote machine, one now has to either:
1. transfer data to local machine to analyze (quite an effort if it's much data)
2. analyze remotely, generate remote graphics file, transfer graphics file, open graphics file locally to inspect the result

Both options are far from ideal, and having remote data is not an uncommon thing.

In IDL (interactive data languge), there is such a low-level, non-interactive, X 'device' that one can plot to.  It is as fast for remote uses as for local uses.

Unfortunately, I'm not an X expert myself, but I'd be very interested in collaborating on a 'minimalist X backend' effort.

Is anybody interested?

Best,
Daan

[matplotlib-devel] another change request to markers.py

[Alexander H. <mat...@2s...>]

Sorry for the multiple mailings.

in makers.py I request to change

      def _set_custom_marker(self, path):
          verts = path.vertices
          rescale = max(np.max(np.abs(verts[:,0])),
np.max(np.abs(verts[:,1])))
          self._transform = Affine2D().scale(1.0 / rescale)
          self._path = path

to

      def _set_custom_marker(self, path):
          verts = path.vertices
          rescale = np.max(np.sqrt(np.square(verts[:,0]) +
np.square(verts[:,1])))
          self._transform = Affine2D().scale(1.0 / rescale)
          self._path = path

such that the symbol *radius* is normalized to 1.0

This way my previous example give better results if the symbol is rotated:

import matplotlib.path as path
from matplotlib.transforms import Affine2D

# define codes
P = path.Path
Pm = P.MOVETO
Pl = P.LINETO
Pc = P.CLOSEPOLY
c = [Pm] + [Pl]*3 + [Pc]
cx=c*2

# define basic path
r=np.array(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
# we add second closed path of half size but reverse parity
rh=0.5*r[::-1]
rx = np.vstack((r,rh))
p = path.Path(rx,codes=cx)

x = np.linspace(0,1,10)**2
plot(x,c='r',marker=p,ms=10)

pr = p.transformed(Affine2D().rotate_deg(45.))
plot(x,c='r',marker=pr,ms=10)

show()

I think this is how it is "meant" to be, but maybe you have to add a
parameter to allow people recover the current behavior in that case.

-Alexander

====
I just like round cows better than square cows.

[matplotlib-devel] another change request to markers.py

[Alexander H. <al...@ph...>]

in makers.py I request to change

     def _set_custom_marker(self, path):
         verts = path.vertices
         rescale = max(np.max(np.abs(verts[:,0])), 
np.max(np.abs(verts[:,1])))
         self._transform = Affine2D().scale(1.0 / rescale)
         self._path = path

to

     def _set_custom_marker(self, path):
         verts = path.vertices
         rescale = np.max(np.sqrt(np.square(verts[:,0]) + 
np.square(verts[:,1])))
         self._transform = Affine2D().scale(1.0 / rescale)
         self._path = path

such that the symbol *radius* is normalized to 1.0

This way my previous example give better results if the symbol is rotated:

import matplotlib.path as path
from matplotlib.transforms import Affine2D

# define codes
P = path.Path
Pm = P.MOVETO
Pl = P.LINETO
Pc = P.CLOSEPOLY
c = [Pm] + [Pl]*3 + [Pc]
cx=c*2

# define basic path
r=np.array(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
# we add second closed path of half size but reverse parity
rh=0.5*r[::-1]
rx = np.vstack((r,rh))
p = path.Path(rx,codes=cx)

x = np.linspace(0,1,10)**2
plot(x,c='r',marker=p,ms=10)

pr = p.transformed(Affine2D().rotate_deg(45.))
plot(x,c='r',marker=pr,ms=10)

show()

I think this is how it is "meant" to be, but maybe you have to add a 
parameter to allow people recover the current behavior in that case.

-Alexander

====
I just like round cows better than square cows.

[matplotlib-devel] fix to markers.py

[Alexander H. <mat...@2s...>]

In [1]: matplotlib.__version__
Out[1]: '1.2.x'


~/matplotlib/lib/matplotlib>diff  markers.py_broken markers.py
190c190
<         path = Path(verts)
---
 >         path = Path(self._marker)

PS - I tried to log into
https://github.com/matplotlib/matplotlib/issues
using my mailing list password to create a bug report, but it would not 
accept it, so you get it this way.

DOCUMENTATION NOTES

1) in the table for marker vertices it states

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_marker

verts	a list of (x, y) pairs in range (0, 1)

it really should be just normalized or abs(1), (0,0) being center, and 
hence the (x,y) values should be in the range (-1,+1).  Would be good to 
add an example

x=np.linspace(0,1,10)**2
plot(x,c='r',marker=((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)),ms=10)

2) the source also support to just provide a path as a marker, which (a) 
is cool, and (b) seemed natural as internal many things are done a 
paths, and even complies paths are generated from the $...$ syntax math. 
  In any case, this should be added to the documentation for allowed markers

path	a matplotlib.path.Path object

import matplotlib.path as path
x = np.linspace(0,1,10)**2
p = path.Path(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
plot(x,c='r',marker=p,ms=10)

or a cool example that you may want tot add to the library...

import matplotlib.path as path

# define codes
P = path.Path
Pm = P.MOVETO
Pl = P.LINETO
Pc = P.CLOSEPOLY
c = [Pm] + [Pl]*3 + [Pc]
cx=c*2

# define basic path
r=np.array(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
# we add second closed path of half size but reverse parity
rh=0.5*r[::-1]
rx = np.vstack((r,rh))
p = path.Path(rx,codes=cx)

x = np.linspace(0,1,10)**2
plot(x,c='r',marker=p,ms=10)

PS - I guess I need to figure out how to do such updates w/o requesting 
action from the lest eventually.

Just to emphasize (2a): COOL!!!

Wishlist:
Can we add a "transform" parameter to overwrite self._transform?
I suppose this would have to go many places.

"set_marker_transform"

Maybe add to MarkerStyle

from transforms import Transform
def self.set_transform(self, transform = IdentityTransform()):
     assert isinstance(x, Transform)					
     self._transfrom = transfrom()


Maybe less fancy, and better for starters, to add an angle

"set_marker_rotation(angle)"

using

Affine2D().rotate_deg(angle)


-Alexander

Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?

[Fernando P. <fpe...@gm...>]

On Sat, Dec 17, 2011 at 11:56 AM, John Hunter <jd...@gm...> wrote:
> Did you test? I did enable the same old fer_perez sf account you've always had.  I was just referring to you by your email moniker in the post above. If it's still not working, I'll see if there is some other setting that needs tweaking.

OK, it worked now.  I was using before an auto-generated password that
was OK for web login but had funny quote characters that were
confusing the svn login (probably being escaped by the shell).  I
changed that to a more normal password, and now I was able to push.
Sorry for the confusion, and thanks!

Doing these updates should be easy and infrequent enough that I'm
happy to push them by hand when needed, just ping me.

Checked and the system mpl on ubuntu 11.10 can now fetch stinkbug correctly:

In [3]: matplotlib.__version__
Out[3]: '1.0.1'

In [4]: cbook.get_sample_data('stinkbug.png')
Out[4]: <open file
'/home/fperez/.matplotlib/sample_data/stinkbug.png', mode 'rb' at
0x2860b70>

Cheers,

f

Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?

[John H. <jd...@gm...>]

> my SF username is fer_perez, by the time I joined fperez was taken on
> SF.  If you have a chance of fixing this, I'll try to push again.

Did you test? I did enable the same old fer_perez sf account you've always had.  I was just referring to you by your email moniker in the post above. If it's still not working, I'll see if there is some other setting that needs tweaking. 

> 

Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?

[Fernando P. <fpe...@gm...>]

Hey John,

On Sat, Dec 17, 2011 at 5:23 AM, John Hunter <jd...@gm...> wrote:
> I've selectively enabled your (fperez) write access to the repo.  Give
> it a try and let me know if you have any problems.

my SF username is fer_perez, by the time I joined fperez was taken on
SF.  If you have a chance of fixing this, I'll try to push again.

Thanks!

f

Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?

[John H. <jd...@gm...>]

On Fri, Dec 16, 2011 at 7:17 PM, Fernando Perez <fpe...@gm...> wrote:
> OK, thanks for trying.  Next week we can see if John can reopen it for
> this.  I think there's no danger of anyone mistakenly committing any
> real work there anymore.

I've selectively enabled your (fperez) write access to the repo.  Give
it a try and let me know if you have any problems.


Thanks,
JDH