matplotlib-devel — matplotlib developers

[matplotlib-devel] Qt close bug revisited

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

I'm getting a strange error when multiple figures are created *without a
call to show*. Here's the traceback:

Traceback (most recent call last):
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4.py", line
151, in <lambda>
    lambda: self.close_event())
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1564, in close_event
    self.callbacks.process(s, event)
AttributeError: 'FigureCanvasQTAgg' object has no attribute 'callbacks'


Here's a simple test case:

import matplotlib.pyplot as plt
fig = plt.figure()
plt.plot([0, 1])
fig = plt.figure()
plt.plot([0, 1])


This issue appears in versions after the PR to fix the Qt4 close
bug<https://github.com/matplotlib/matplotlib/pull/716>.
The error occurs even without the `plot` calls, but the failures aren't as
consistent (the error will randomly disappear).

Note that sticking a call to `plt.show()` at the end and then manually
closing the figures does not seem to produce this error. I'm having a
difficult time locating the source of the bug: when I stick a pdb trace in
the code, the error doesn't get raised.

Can anyone reproduce this issue?

-Tony

Re: [matplotlib-devel] wxMPL patch

[Thomas K. <th...@kl...>]

On 1 May 2012 17:26, Chris Barker <chr...@no...> wrote:
> Would there be a problem bringing it in to MPL in that case?

Not from the license point of view - the X11 license is another
permissive BSD-style license. I was just furnishing that detail. ;-)

Thomas

Re: [matplotlib-devel] wxMPL patch

[Chris B. <chr...@no...>]

On Tue, May 1, 2012 at 9:31 AM, Benjamin Root

> AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect it
> would fit best as a mpl_toolkit.

yes -- I figured that was most likely.

> P.S. - Of course, you do realize that you are essentially making yourself
> the de facto maintainer of it, right?

Well, me or Matt or Carlo -- we'll fight over that among ourselves.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] wxMPL patch

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

On Tue, May 1, 2012 at 12:26 PM, Chris Barker <chr...@no...> wrote:

> On Tue, May 1, 2012 at 9:23 AM, Thomas Kluyver <th...@kl...>
> wrote:
> > On 1 May 2012 17:04, Chris Barker <chr...@no...> wrote:
> >> (the license looks BSD-ish to me)
> >
> > At a glance, I think it's the X11 license, aka MIT license.
>
>
> Would there be a problem bringing it in to MPL in that case?
>
> -Chris
>
>
AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect it
would fit best as a mpl_toolkit.

Ben Root

P.S. - Of course, you do realize that you are essentially making yourself
the de facto maintainer of it, right?

Re: [matplotlib-devel] wxMPL patch

[Chris B. <chr...@no...>]

On Tue, May 1, 2012 at 9:23 AM, Thomas Kluyver <th...@kl...> wrote:
> On 1 May 2012 17:04, Chris Barker <chr...@no...> wrote:
>> (the license looks BSD-ish to me)
>
> At a glance, I think it's the X11 license, aka MIT license.


Would there be a problem bringing it in to MPL in that case?

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] wxMPL patch

[Chris B. <chr...@no...>]

Hi folks,

It seems Ken McIvor has more or less disappeared. However, his wxMPL
code is still useful and there are a few of us that are interested in
maintaining it.

What would be the procedure for getting it into a more "official"
location -- like maybe a matplotlib toolkit? Or even mixed right in
with the code (i.e. import matplotlib.wxmpl)?

It's one file -- there really isn't that much to it, but it's nice to have.

http://agni.phys.iit.edu/~kmcivor/wxmpl/

(the license looks BSD-ish to me)

Thanks,
   -Chris





On Mon, Apr 30, 2012 at 11:16 AM, Chris Barker <chr...@no...> wrote:
> Hi Folks,
>
> I can't seem to find Ken McIvor -- Ken are you here?
>
> Anyway, here's a tiny patch of wxMPL to make it work with wxPython 2.9
> -- the only change is here, around line 1126:
>
>       ## the following changed according to Robin Dunn's advice for 2.9
>       ##    -- but it probably wasn't working right before!
>        #topwin.Connect(wx.ID_ANY, self.GetId(), wx.wxEVT_ACTIVATE,
> self.OnActivate)
>        topwin.Connect(self.GetId(), wx.ID_ANY, wx.wxEVT_ACTIVATE,
> self.OnActivate)
>
> This change works fine with wxPython2.8, also.
>
> Attached is the whole file.
>
> -Chris
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chr...@no...



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[matplotlib-devel] wxMPL patch

[Chris B. <chr...@no...>]

Hi Folks,

I can't seem to find Ken McIvor -- Ken are you here?

Anyway, here's a tiny patch of wxMPL to make it work with wxPython 2.9
-- the only change is here, around line 1126:

       ## the following changed according to Robin Dunn's advice for 2.9
       ##    -- but it probably wasn't working right before!
        #topwin.Connect(wx.ID_ANY, self.GetId(), wx.wxEVT_ACTIVATE,
self.OnActivate)
        topwin.Connect(self.GetId(), wx.ID_ANY, wx.wxEVT_ACTIVATE,
self.OnActivate)

This change works fine with wxPython2.8, also.

Attached is the whole file.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[matplotlib-devel] Fwd: Docs failing to build

[Thomas K. <th...@kl...>]

Hi,

In the last couple of days, the daily builds on Launchpad have been
choking on the docs. They get to "reading sources... [ 91%]
faq/howto_faq", then seemingly lock up until the queue manager aborts
the build. It claims there's 2h30 of inactivity before that happens,
so it looks like something really is wrong.

Example build log:
https://launchpadlibrarian.net/102978621/buildlog_ubuntu-precise-i386.matplotlib_1.1.0%2B6017%2B10%7Eprecise1_FAILEDTOBUILD.txt.gz

It appears to be this big commit which broke it (unless it was an
external factor like some change to Sphinx):
https://github.com/matplotlib/matplotlib/commit/76665d059523cf0b89695570dc311ce8b50d4a4b

Has anyone else seen this, or do you have any ideas what might be causing it?

Thanks,
Thomas

P.S. Apologies to anyone getting this twice.

Re: [matplotlib-devel] Bug: errorbar caps require mew!=0

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

On Tue, Apr 24, 2012 at 7:49 AM, Mike Kaufman <mc...@gm...> wrote:

> If mew=0, then the caps on errorbars are not drawn regardless of the
> setting of the "capsize" option. I don't think this should be the
> behavior, it certainly caught me off guard, since I had mew=0 set in
> rcParams.
>
> This is present as of 5b499f0180befea04fab7bfda17ba3ad7cf2380e
> (Mar 22nd master)
>
> M
>
>
This is indeed confusing and I have been meaning to do something about this
for a while now (yet another item in my todo list...).  Keep in mind that
there is actually no discrepancy.  The marker is turned onto its side.  So
the marker edge width parameter actually effects the cap's thickness.  So,
having a finite capsize, but a zero thickness should result in no cap being
drawn.

But it is totally unintuitive that mew should have anything to do with the
cap thickness and what should be done is introduce a new kwarg "capthick"
or "capheight" and eventually have it completely replace the responsibility
of mew in errorbars.

Ben Root

Re: [matplotlib-devel] Inconsistent naming of legend points

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

On Thu, Apr 19, 2012 at 3:04 AM, Jae-Joon Lee <lee...@gm...> wrote:

> I think what we may do is to make the default value of "scatterponts"
> to None, and if None, set it to the value of numpoints.
> But, I want to hear how others think about it.
>
> Regards,
>
> -JJ
>
>
I think that would be reasonable.  And maybe put "scatterpoints" onto a
deprecation path?

Cheers!
Ben Root

Re: [matplotlib-devel] bug in font display using png backend

[Detlef M. <det...@ki...>]

yep, it works. Thanks for fixing it so quickly!

On 23.04.2012 23:34, Michael Droettboom wrote:
> Git bisect shows that this was introduced in f57dddc20625. Looking at
> the github comments for that commit:
>
> https://github.com/matplotlib/matplotlib/commit/f57dddc20625809436956675d23b09baddcc9e0e
>
>
> strange enough the problem and solution are already discussed, it just
> seems the solution never made it in.
>
> This should now be fixed in 48c31f7ff660
>
> Mike
>

[matplotlib-devel] Bug: errorbar caps require mew!=0

[Mike K. <mc...@gm...>]

If mew=0, then the caps on errorbars are not drawn regardless of the 
setting of the "capsize" option. I don't think this should be the 
behavior, it certainly caught me off guard, since I had mew=0 set in 
rcParams.

This is present as of 5b499f0180befea04fab7bfda17ba3ad7cf2380e
(Mar 22nd master)

M

Re: [matplotlib-devel] bug in font display using png backend

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

Git bisect shows that this was introduced in f57dddc20625.  Looking at 
the github comments for that commit:

https://github.com/matplotlib/matplotlib/commit/f57dddc20625809436956675d23b09baddcc9e0e

strange enough the problem and solution are already discussed, it just 
seems the solution never made it in.

This should now be fixed in 48c31f7ff660

Mike

On 04/23/2012 10:33 AM, Detlef Maurel wrote:
> Hi all,
>
> there is a problem in the font display in the newest trunk version of 
> matplotlib (git rev. 76665d059523cf)
>
> I ran a clean installation and the test script. You can see in the 
> attachment that the fonts are somehow screwed up. It seems to depend 
> on the graphics backend. In the screenshot, the title is broken. In 
> the png output, only the axis labels are broken. In the pdf, 
> everything looks fine.
>
> It looks like this bug has been introduced after tag v1.1.0 (I 
> switched back to the tag and the fonts look fine there).
>
> If you want me to run further tests, please let me know.
>
>
> Detlef
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] bug in font display using png backend

[Detlef M. <det...@ki...>]

Hi all,

there is a problem in the font display in the newest trunk version of 
matplotlib (git rev. 76665d059523cf)

I ran a clean installation and the test script. You can see in the 
attachment that the fonts are somehow screwed up. It seems to depend on 
the graphics backend. In the screenshot, the title is broken. In the png 
output, only the axis labels are broken. In the pdf, everything looks fine.

It looks like this bug has been introduced after tag v1.1.0 (I switched 
back to the tag and the fonts look fine there).

If you want me to run further tests, please let me know.


Detlef

Re: [matplotlib-devel] Inconsistent naming of legend points

[Chao Y. <cha...@gm...>]

Yes, I am only a user not a developer.
the different names make me confused at the beginning, it's only last night
I realised this
after more than 1 years use of matplotlib.
New beginners would be less confused if a unified name is used.

Chao

2012/4/19 Jae-Joon Lee <lee...@gm...>

> I think what we may do is to make the default value of "scatterponts"
> to None, and if None, set it to the value of numpoints.
> But, I want to hear how others think about it.
>
> Regards,
>
> -JJ
>
>
>
> On Fri, Mar 30, 2012 at 11:39 PM, Pim Schellart <P.S...@as...>
> wrote:
> > Dear all,
> >
> > there is an inconsistency in the naming of the variable that describes
> > the number of points to display in the legend.
> > For `plt.plot` and `plt.errorbar` it is called "numpoints" but for
> > `plt.scatter` it is called "scatterpoints".
> > It would be less confusing if both could be set with a simple
> > "numpoints" in the legend function.
> > Please let me know what you think.
> >
> > Kind regards,
> >
> > Pim Schellart
> >
> >
> ------------------------------------------------------------------------------
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> > http://p.sf.net/sfu/sfd2d-msazure
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

Re: [matplotlib-devel] Inconsistent naming of legend points

[Jae-Joon L. <lee...@gm...>]

I think what we may do is to make the default value of "scatterponts"
to None, and if None, set it to the value of numpoints.
But, I want to hear how others think about it.

Regards,

-JJ



On Fri, Mar 30, 2012 at 11:39 PM, Pim Schellart <P.S...@as...> wrote:
> Dear all,
>
> there is an inconsistency in the naming of the variable that describes
> the number of points to display in the legend.
> For `plt.plot` and `plt.errorbar` it is called "numpoints" but for
> `plt.scatter` it is called "scatterpoints".
> It would be less confusing if both could be set with a simple
> "numpoints" in the legend function.
> Please let me know what you think.
>
> Kind regards,
>
> Pim Schellart
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

[Jostein Bø F. <jos...@gm...>]

Ben,

That sounds great, especially regarding the test images. I don't know
how the image comparison tests work, that's why I kept it very
fundamental.

Thanks!

Jostein.

Den 14:59 17. april 2012 skrev Benjamin Root <ben...@ou...> følgende:
>
>
> On Tue, Apr 17, 2012 at 3:30 AM, Jostein Bø Fløystad
> <jos...@gm...> wrote:
>>
>> Hi Benjamin,
>>
>> and thanks for looking into this. The traceback you showed in your
>> post is the original one that I see before applying the second patch.
>> After applying the second patch, I do not see this traceback any more,
>> and I get the results I expect. In other words, I'm unable to
>> reproduce the behaviour you get (with the patches applied to current
>> master). Would it be possible for you to send the code in quickshow.py
>> that triggers this behaviour?
>>
>> You seemed uncertain that you had the full patch. The second patch
>> only changes a single line of code, namely line 1243 of image.py. An
>> excerpt of the patch:
>>
>> -    figsize = [x / float(dpi) for x in arr.shape[::-1]]
>> +    figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>> For me, this is enough to make imshow work for MxNx3 (or 4).
>>
>> Cheers,
>>
>> Jostein.
>>
>
> Josten,
>
> Sorry for the noise.  I forgot to install the patched version of mpl.  Your
> second patch certainly does fix the bug and should be committed.  As for the
> first patch that has the test, I think it would be better to actually create
> some test data and test image.  I am working on creating such a test set for
> a related bug in imshow() and imsave().  Once I do that, I can make a pull
> request that can include both our patches.
>
> Cheers!
> Ben Root
>

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

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

On Tue, Apr 17, 2012 at 3:30 AM, Jostein Bø Fløystad <
jos...@gm...> wrote:

> Hi Benjamin,
>
> and thanks for looking into this. The traceback you showed in your
> post is the original one that I see before applying the second patch.
> After applying the second patch, I do not see this traceback any more,
> and I get the results I expect. In other words, I'm unable to
> reproduce the behaviour you get (with the patches applied to current
> master). Would it be possible for you to send the code in quickshow.py
> that triggers this behaviour?
>
> You seemed uncertain that you had the full patch. The second patch
> only changes a single line of code, namely line 1243 of image.py. An
> excerpt of the patch:
>
> -    figsize = [x / float(dpi) for x in arr.shape[::-1]]
> +    figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
> For me, this is enough to make imshow work for MxNx3 (or 4).
>
> Cheers,
>
> Jostein.
>
>
Josten,

Sorry for the noise.  I forgot to install the patched version of mpl.  Your
second patch certainly does fix the bug and should be committed.  As for
the first patch that has the test, I think it would be better to actually
create some test data and test image.  I am working on creating such a test
set for a related bug in imshow() and imsave().  Once I do that, I can make
a pull request that can include both our patches.

Cheers!
Ben Root

Re: [matplotlib-devel] [Matplotlib-users] Bug in Triangulation causes infinite loop if 4 or more duplicate points are used in tricontour()

[Ian T. <ian...@gm...>]

On 16 April 2012 23:36, Damon McDougall <D.M...@wa...> wrote:

> On Monday, 16 April 2012 at 16:34, Kacper Kowalik wrote:
>
>
> On 16 Apr 2012 22:31, "Damon McDougall" <D.M...@wa...> wrote:
> >
> > Hi Kacper,
> >
> > Just to be clear, is it tri.Triangulation(x, y) that hangs, or is it
> plt.tricontour(…)?
>
> It's plt.tricontour that hangs, tri.Triangulation properly issues warning
> about duplicates.
> Cheers,
> Kacper
>
> > On Monday, 16 April 2012 at 14:28, Kacper Kowalik wrote:
>
> >>
> >> Hi,
> >> I haven't been able to pin point it exactly but following script:
> >>
> >> import matplotlib.pyplot as plt
> >> import matplotlib.tri as tri
> >> import numpy as np
> >> from numpy.random import uniform, seed
> >>
> >> seed(0)
> >> npts = 200
> >> x = uniform(-2,2,npts)
> >> y = uniform(-2,2,npts)
> >> z = x*np.exp(-x**2-y**2)
> >>
> >> y[1:3] = x[0] # 4 or more duplicate points make tricontour hang!!!
> >> x[1:3] = y[0]
>
> You should call z = x*np.exp(-x**2-y**2) _before_ changing the points
> you're triangulating.
> Having said that, I see the same behaviour even if I change the vertices
> before I compute z.
>
> >> triang = tri.Triangulation(x, y)
> >> plt.tricontour(x, y, z, 15, linewidths=0.5, colors='k')
> >>
> >> plt.show()
> >>
> >>
> >> causes infinite loop in _tri.so. It happens in matplotlib-1.1.0 as well
> >> as git HEAD.
> >> I understand that my input is not exactly valid, but I'd rather see MPL
> >> die than occupy my box for eternity ;)
> >> Best regards,
> >> Kacper
>
> I think the reason it's hanging is because you're trying to plot the
> contours of a function that is defined on an invalid triangulation (edges
> cross at points that are not in the vertex set). I think the best way to
> deal with this is to write a helper function to check the triangulation is
> valid. If it isn't, either tri.Triangulation(x, y) should fail, or the
> plotter should fail.
>
> Anybody else have any suggestions?
>

We can definitely do better here.  I have created a issue request on github:
https://github.com/matplotlib/matplotlib/issues/838
and will investigate further.

Ian

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

[Jostein Bø F. <jos...@gm...>]

Hi Benjamin,

and thanks for looking into this. The traceback you showed in your
post is the original one that I see before applying the second patch.
After applying the second patch, I do not see this traceback any more,
and I get the results I expect. In other words, I'm unable to
reproduce the behaviour you get (with the patches applied to current
master). Would it be possible for you to send the code in quickshow.py
that triggers this behaviour?

You seemed uncertain that you had the full patch. The second patch
only changes a single line of code, namely line 1243 of image.py. An
excerpt of the patch:

-    figsize = [x / float(dpi) for x in arr.shape[::-1]]
+    figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]

For me, this is enough to make imshow work for MxNx3 (or 4).

Cheers,

Jostein.

Den 23:00 16. april 2012 skrev Benjamin Root <ben...@ou...> følgende:
>
> On Sat, Apr 7, 2012 at 11:25 AM, Jostein Bø Fløystad
> <jos...@gm...> wrote:
>>
>> I've had problems saving MxNx3 (RGB) numpy arrays as images using
>> imsave. It fails with an exception, and the problem seems to be line
>> 1243 in image.py:
>>
>> figsize = [x / float(dpi) for x in arr.shape[::-1]]
>>
>> The purpose of arr.shape[::-1] seems to be to reorder the height and
>> width dimensions. It works as intended for MxN arrays, but not NxMx3
>> arrays -- they cause a function to complain about an argument too
>> many.
>>
>> I have modified the above line to use (arr.shape[1], arr.shape[0])
>> instead of arr.shape[::-1], and that solves the problem for me, and I
>> get the output I expect (and the code still passes all tests it should
>> pass). However, there could very well be subtleties in the codebase
>> that I don't know about.
>>
>> The attached patches add a simple test case, the above mentioned
>> change and a few updates to the documentation of imsave.
>>
>> Best,
>>
>> Jostein.
>>
>
> Jostein,
>
> That second patch certain fixes that part of the bug, but I still can't save
> an NxMx3 (or 4) array using imsave().  Are you sure this is all of the
> patch?
>
> I get the following exception:
>
> ```
> Traceback (most recent call last):
>   File "quickshow.py", line 106, in <module>
>     plt.imsave(stem + '.png', cm(d))
>   File
> "/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/pyplot.py",
> line 1757, in imsave
>     return _imsave(*args, **kwargs)
>   File
> "/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/image.py",
> line 1244, in imsave
>     fig = Figure(figsize=figsize, dpi=dpi, frameon=False)
>   File
> "/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/figure.py",
> line 269, in __init__
>     self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
> TypeError: from_bounds() takes exactly 4 arguments (5 given)
> ```
>
> Cheers!
> Ben Root
>

Re: [matplotlib-devel] [Matplotlib-users] Bug in Triangulation causes infinite loop if 4 or more duplicate points are used in tricontour()

[Damon M. <D.M...@wa...>]

On Monday, 16 April 2012 at 16:34, Kacper Kowalik wrote:
>  
> On 16 Apr 2012 22:31, "Damon McDougall" <D.M...@wa... (mailto:D.M...@wa...)> wrote:
> >
> > Hi Kacper,
> >
> > Just to be clear, is it tri.Triangulation(x, y) that hangs, or is it plt.tricontour(…)?  
> It's plt.tricontour that hangs, tri.Triangulation properly issues warning about duplicates.
> Cheers,
> Kacper  
> > On Monday, 16 April 2012 at 14:28, Kacper Kowalik wrote:
> >>
> >> Hi,
> >> I haven't been able to pin point it exactly but following script:
> >>
> >> import matplotlib.pyplot as plt
> >> import matplotlib.tri as tri
> >> import numpy as np
> >> from numpy.random import uniform, seed
> >>
> >> seed(0)
> >> npts = 200
> >> x = uniform(-2,2,npts)
> >> y = uniform(-2,2,npts)
> >> z = x*np.exp(-x**2-y**2)
> >>
> >> y[1:3] = x[0] # 4 or more duplicate points make tricontour hang!!!
> >> x[1:3] = y[0]
You should call z = x*np.exp(-x**2-y**2) _before_ changing the points you're triangulating.
Having said that, I see the same behaviour even if I change the vertices before I compute z.
> >> triang = tri.Triangulation(x, y)
> >> plt.tricontour(x, y, z, 15, linewidths=0.5, colors='k')
> >>
> >> plt.show()
> >>
> >>
> >> causes infinite loop in _tri.so. It happens in matplotlib-1.1.0 as well
> >> as git HEAD.
> >> I understand that my input is not exactly valid, but I'd rather see MPL
> >> die than occupy my box for eternity ;)
> >> Best regards,
> >> Kacper
I think the reason it's hanging is because you're trying to plot the contours of a function that is defined on an invalid triangulation (edges cross at points that are not in the vertex set). I think the best way to deal with this is to write a helper function to check the triangulation is valid. If it isn't, either tri.Triangulation(x, y) should fail, or the plotter should fail.

Anybody else have any suggestions?
  
--
Damon McDougall
d.m...@wa... (mailto:d.m...@wa...)
http://damon.is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[matplotlib-devel] imsave() and cmap

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

Thanks to a patch a bit while back for ListedColormap that allowed for
alphas to be given, I should now be able to use imshow() and imsave() with
colormaps.  However, I find that the results are not correct. Particularly,
the alpha values seem to be assigned incorrectly.  I am still working on
making a stand-alone version to demonstrate the problem, but has anyone
else noticed this?

Note,

plt.imshow(d, cmap=cm)

produces an incorrect result while

plt.imshow(cm(d))

produces a correct result.  However, due to a bug in imsave, I can't do the
latter as a work-around.

Thanks,
Ben Root

Re: [matplotlib-devel] PATCH: Accept color/alpha in imsave

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

On Sat, Apr 7, 2012 at 11:25 AM, Jostein Bø Fløystad <
jos...@gm...> wrote:

> I've had problems saving MxNx3 (RGB) numpy arrays as images using
> imsave. It fails with an exception, and the problem seems to be line
> 1243 in image.py:
>
> figsize = [x / float(dpi) for x in arr.shape[::-1]]
>
> The purpose of arr.shape[::-1] seems to be to reorder the height and
> width dimensions. It works as intended for MxN arrays, but not NxMx3
> arrays -- they cause a function to complain about an argument too
> many.
>
> I have modified the above line to use (arr.shape[1], arr.shape[0])
> instead of arr.shape[::-1], and that solves the problem for me, and I
> get the output I expect (and the code still passes all tests it should
> pass). However, there could very well be subtleties in the codebase
> that I don't know about.
>
> The attached patches add a simple test case, the above mentioned
> change and a few updates to the documentation of imsave.
>
> Best,
>
> Jostein.
>
>
Jostein,

That second patch certain fixes that part of the bug, but I still can't
save an NxMx3 (or 4) array using imsave().  Are you sure this is all of the
patch?

I get the following exception:

```
Traceback (most recent call last):
  File "quickshow.py", line 106, in <module>
    plt.imsave(stem + '.png', cm(d))
  File
"/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/pyplot.py",
line 1757, in imsave
    return _imsave(*args, **kwargs)
  File
"/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/image.py",
line 1244, in imsave
    fig = Figure(figsize=figsize, dpi=dpi, frameon=False)
  File
"/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/figure.py",
line 269, in __init__
    self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
TypeError: from_bounds() takes exactly 4 arguments (5 given)
```

Cheers!
Ben Root

[matplotlib-devel] Matplotlib daily builds PPA

[Thomas K. <th...@kl...>]

Apologies if you receive this twice - I joined the mailing list with
one address, then posted from another. Mods, feel free to bin the
other copy of the post.

If you want to get more people testing the next version, I've set up a
PPA to build the development version of matplotlib nightly for Ubuntu
Precise. This includes building a Python 3 binary package - so it's
possible to get a basic scientific Python 3 environment without having
to compile anything locally.

Use it at your own risk, because I'm still learning the ropes of
packaging. I've checked that it imports and can display a simple plot.
If you want to improve the packaging stuff, launchpad 'merge
proposals' are welcome:
https://code.launchpad.net/~takluyver/matplotlib/debian-daily

Thanks,
Thomas

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

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

I started reading some of Adobe's documentation to find out if there's
something I've overlooked, and noticed that when I read the PDF
Reference in Preview.app, some example images have zoom-dependent
gridlines that look a lot like the output from pcolor. If even Adobe
creates PDF files that have this kind of artifacts, maybe it's a
rendering bug in the other viewers, or possibly the imaging model is
underspecified.

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