matplotlib-devel Mailing List for matplotlib (Page 2)

On 1/13/12 12:53 , Tony Yu wrote:
>
> On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg <gel...@fr...
> <mailto:gel...@fr...>> wrote:
>
>     If you are a macosx backend user, you are welcomed to test the following
>     branch: https://github.com/gellule/matplotlib. With the branch, when
>     issuing a pylab.show() in non-interactive mode, the plot windows should
>     appear in the foreground with focus, instead of appearing in the
>     background. It should make things a little easier for you.
>
>
> This works as advertised on my system (plot window grabs focus when
> running scripts in MacVim, Terminal, and IPython when in non-interactive
> mode). Unfortunately, I tend to use the QT4Agg backend, which also
> leaves plot windows in the background. Maybe I'd switch to the macosx
> backend with this addition.

Thanks!

>     I am also curious to know what people think of making pylab.show() also
>     yield the focus to the plot windows in -interactive- mode? All the other
>     commands update the plot windows automatically, keeping the focus in the
>     python interpreter. So pylab.show() would only do that: yield the focus
>     to the plot windows. That is not in the branch (yet).
>
>
> I'd lean toward no: the plot window shouldn't grab focus in interactive
> mode. I have some scripts that take command-line input in-between plot
> calls. If the plot window grabbed focus, then I'd have to switch focus
> back to enter input. This probably isn't a common use case, though.

But you don't use show() in interactive mode, do you? The focus grab 
would not happen until you call show().

I other words, show() would always send the focus to the plot windows. 
But depending on how interactive is set, it would block or not. If you 
are in interactive mode and don't want to send the focus to the plot 
windows, you would have to not call show().

-Julien

On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg <gel...@fr...> wrote:

> If you are a macosx backend user, you are welcomed to test the following
> branch: https://github.com/gellule/matplotlib. With the branch, when
> issuing a pylab.show() in non-interactive mode, the plot windows should
> appear in the foreground with focus, instead of appearing in the
> background. It should make things a little easier for you.
>

This works as advertised on my system (plot window grabs focus when running
scripts in MacVim, Terminal, and IPython when in non-interactive mode).
Unfortunately, I tend to use the QT4Agg backend, which also leaves plot
windows in the background. Maybe I'd switch to the macosx backend with this
addition.


> I am also curious to know what people think of making pylab.show() also
> yield the focus to the plot windows in -interactive- mode? All the other
> commands update the plot windows automatically, keeping the focus in the
> python interpreter. So pylab.show() would only do that: yield the focus
> to the plot windows. That is not in the branch (yet).
>

I'd lean toward no: the plot window shouldn't grab focus in interactive
mode. I have some scripts that take command-line input in-between plot
calls. If the plot window grabbed focus, then I'd have to switch focus back
to enter input. This probably isn't a common use case, though.

-Tony


>
> Cheers,
>
> -Gellule/Julien
>
>

If you are a macosx backend user, you are welcomed to test the following 
branch: https://github.com/gellule/matplotlib. With the branch, when 
issuing a pylab.show() in non-interactive mode, the plot windows should 
appear in the foreground with focus, instead of appearing in the 
background. It should make things a little easier for you.

I am also curious to know what people think of making pylab.show() also 
yield the focus to the plot windows in -interactive- mode? All the other 
commands update the plot windows automatically, keeping the focus in the 
python interpreter. So pylab.show() would only do that: yield the focus 
to the plot windows. That is not in the branch (yet).

Cheers,

-Gellule/Julien

Ok, this was my bad. I was under the [mistaken] impression (and in 
retrospect I'm not sure why) that the AxesGrid call just set up the 
geometry and the plot calls actually created the axes.

Thanks for setting me straight.

M

On 1/11/12 9:05 PM, Paul Ivanov wrote:
> Hi Mike,
>
> Mike Kaufman, on 2012-01-11 19:30,  wrote:
>> Given the code snippet below with clf() #1 uncommented works like one
>> would expect - both plots are drawn. If #1 is commented out and #2 is
>> uncommented, then the figure is cleared and neither plot is drawn. Is
>> this the correct behavior? It seems like a bug to me.
>
> Seems to me like this is the intended behavior and not a bug. I'm
> not sure what you were expecting to happen with that second call
> to clf. You're clearing the whole figure, so even though the
> axes you have in the grid variable have references to f, f has
> disowned them!
>
>    In [39]: grid = AxesGrid(f, 111, (1,2))
>
>    In [40]: f.axes
>    Out[40]:
>    [<mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb7c002c>,
>     <mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb8948cc>,
>     <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb810dac>,
>     <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb97486c>]
>
>    In [41]: plt.clf()
>
>    In [42]: f.axes
>    Out[42]: []
>
> Perhaps you wanted to simply to clear the individual axes? You
> can do that with [g.cla() for g in grid] instead of your call to
> plt.clf()
>
> best,

Hi Mike,

Mike Kaufman, on 2012-01-11 19:30,  wrote:
> Given the code snippet below with clf() #1 uncommented works like one 
> would expect - both plots are drawn. If #1 is commented out and #2 is 
> uncommented, then the figure is cleared and neither plot is drawn. Is 
> this the correct behavior? It seems like a bug to me.

Seems to me like this is the intended behavior and not a bug. I'm
not sure what you were expecting to happen with that second call
to clf. You're clearing the whole figure, so even though the
axes you have in the grid variable have references to f, f has
disowned them!

  In [39]: grid = AxesGrid(f, 111, (1,2))
  
  In [40]: f.axes
  Out[40]: 
  [<mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb7c002c>,
   <mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb8948cc>,
   <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb810dac>,
   <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb97486c>]
  
  In [41]: plt.clf()
  
  In [42]: f.axes
  Out[42]: []

Perhaps you wanted to simply to clear the individual axes? You
can do that with [g.cla() for g in grid] instead of your call to
plt.clf()

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Given the code snippet below with clf() #1 uncommented works like one 
would expect - both plots are drawn. If #1 is commented out and #2 is 
uncommented, then the figure is cleared and neither plot is drawn. Is 
this the correct behavior? It seems like a bug to me.

M


import numpy as np
import matplotlib.pyplot as plt
from mpl_toolkits.axes_grid1 import AxesGrid

f = plt.figure(1)
plt.clf() #1
grid = AxesGrid(f, 111, (1,2))
#plt.clf()  #2
grid[0].plot(np.arange(10))
grid[1].plot(np.arange(10))
plt.draw()

Paul Ivanov, on 2012-01-09 13:56,  wrote:
> kei...@bt..., on 2012-01-09 11:47,  wrote:
> > "Celsius" is spelled wrongly every time.
> 
> Thanks for the report, Keith, I'm taking care of this right now.

Done.
https://github.com/matplotlib/matplotlib/commit/e0cf45ed01a9a098a9acbde177812dd9ceee7ec9

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

kei...@bt..., on 2012-01-09 11:47,  wrote:
> "Celsius" is spelled wrongly every time.

Thanks for the report, Keith, I'm taking care of this right now.

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

"Celsius" is spelled wrongly every time.

Keith

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

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

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

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

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

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.

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

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

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.

 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()

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

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.
>

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()
> #~~~~

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()
#~~~~

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