matplotlib-devel Mailing List for matplotlib

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
>

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

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

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
>