matplotlib-devel Mailing List for matplotlib

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.