matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?

[Maximilian A. <max...@gm...>]

Hi Damon,

many thanks for the quick (and positive :)) reply,

> Sounds like a great idea! Would you feel comfortable having a go at an
> implementation? You can make a pull request out of it. The rest of the
> developers can then deliberate and provide feedback for you.

I attached a patch to my previous email which contains an
implementation, but perhaps it didn't make it through to the list? But
since I had to clone the git repository anyway to implement it, I'm
happy to make a pull request, too. I'll have to find out how to do
that since I've never done it before, but I guess it can't be too
difficult. Will give it a shot later today.

Thanks again and best regards,
Max

Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?

[Damon M. <dam...@gm...>]

On Wed, Oct 31, 2012 at 7:04 AM, Maximilian Albert
<max...@gm...> wrote:
> [I sent this email a few weeks ago already, but I wasn't subscribed to
> matplotlib-devel at the time and it seems that the message was never
> approved by the moderator. So here comes my second attempt. :)]
>
> Hi all,
>
> this is my first post to this mailing list, so let me take the
> opportunity to thank everyone involved for an amazing piece of
> software and all the hard work you guys put into it! It is very much
> appreciated indeed.
>
> I have a quick question/suggestion regarding the save() method in the
> matplotlib.animation.Animation class. I recently produced an animation
> in which I needed to set tight bounding boxes when saving the
> individual frames. Obviously savefig() supports this, but there is no
> way to pass this information to the Animation.save() method. Would it
> make sense to let Animation.save() accept additional keyword arguments
> which are simply passed on to savefig() in each step of the animation
> loop? Or am I overlooking potential drawbacks of this approach? A
> simple patch with this idea is attached. Feel free to use it as is or
> to modify at will if you think this is useful.
>
> Many thanks and kind regards,
> Max

Hi Max,

Sounds like a great idea! Would you feel comfortable having a go at an
implementation? You can make a pull request out of it. The rest of the
developers can then deliberate and provide feedback for you.

Best wishes,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?

[Maximilian A. <max...@gm...>]

[I sent this email a few weeks ago already, but I wasn't subscribed to
matplotlib-devel at the time and it seems that the message was never
approved by the moderator. So here comes my second attempt. :)]

Hi all,

this is my first post to this mailing list, so let me take the
opportunity to thank everyone involved for an amazing piece of
software and all the hard work you guys put into it! It is very much
appreciated indeed.

I have a quick question/suggestion regarding the save() method in the
matplotlib.animation.Animation class. I recently produced an animation
in which I needed to set tight bounding boxes when saving the
individual frames. Obviously savefig() supports this, but there is no
way to pass this information to the Animation.save() method. Would it
make sense to let Animation.save() accept additional keyword arguments
which are simply passed on to savefig() in each step of the animation
loop? Or am I overlooking potential drawbacks of this approach? A
simple patch with this idea is attached. Feel free to use it as is or
to modify at will if you think this is useful.

Many thanks and kind regards,
Max

[matplotlib-devel] Fwd: Delaying rc3 (again)

[Damon M. <dam...@gm...>]

Whoops! I copied in the users mailing list by accident. Stupid iPhone gmail
app is stupid.

I might have possibly ruined the rc3 surprise. Sorry about that.

---------- Forwarded message ----------
From: *Damon McDougall*
Date: Tuesday, October 30, 2012
Subject: [matplotlib-devel] Delaying rc3 (again)
To: "Russell E. Owen" <ro...@uw...>
Cc: "mat...@li..." <
mat...@li...>


On Tuesday, October 30, 2012, Russell E. Owen wrote:

> In article <508...@st...>,
>  Michael Droettboom <md...@st...>
>  wrote:
>
> > Agreed!  Thanks to everyone for their hard work.  I think this has
> > shaped up to be a great release.
> >
> > I'm fortunate to have power and connectivity today, so I was able to get
> > a release tested, tagged and uploaded.
> >
> > To our binary builders: as able, it would be great to put the binaries
> > up (or send them to me to do so), and then I'll make an announcement on
> > matplotlib-users.  I really intend (barring any really serious issues)
> > this to be the last rc before the 1.2.0 final.
> >
> > Thanks again,
> > Mike
>
> The Mac binaries are now up. This time it built perfectly on MacOS X
> 10.4; thanks to the folks that worked so hard fixing those build
> problems.
>
> The 32-bit version is not well tested because I have neither inkscape
> nor ghostscript installed on that ancient system, but it passes the
> tests that it can run under those circumstances.
>
> The 64-bit version passes all tests except 2 knownfail and 3 skipped.
>
> -- Russell
>
> P.S. I had to build the 64-bit version twice. The first time I tried to
> build it using the same directory of code that I used to build 32-bit
> version. I first deleted the "build" and "dist" subdirectories and ran
> "python setup.py clean", then built as usual. There were no errors or
> warnings during the build, but the unit tests would not run on the
> results -- complaining of missing modules.
>
> So I built again using a freshly unpacked code directory and that worked
> just fine.
>
> I'm pretty sure I've seen this problem before, but keep forgetting to
> ask about it.
>
> Is this a bug somewhere (e.g. in matplotlib's setup.py or somewhere in
> python) or is there some better way to clear out a python code directory?
>

Yes! I'm sending you a virtual high five! Thanks for thy Russell.


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom



-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Delaying rc3 (again)

[Christoph G. <cg...@uc...>]

On 10/30/2012 8:54 AM, Michael Droettboom wrote:
> Agreed!  Thanks to everyone for their hard work.  I think this has
> shaped up to be a great release.
>
> I'm fortunate to have power and connectivity today, so I was able to get
> a release tested, tagged and uploaded.
>
> To our binary builders: as able, it would be great to put the binaries
> up (or send them to me to do so), and then I'll make an announcement on
> matplotlib-users.  I really intend (barring any really serious issues)
> this to be the last rc before the 1.2.0 final.
>
> Thanks again,
> Mike
>

Looks good: all tests pass on Python 2.6 to 3.3, 32 and 64 bit, on my 
Windows system.

However, the agg_buffer_to_array.py example crashes under some 
circumstances. See 
<https://github.com/matplotlib/matplotlib/issues/1437>. Can anyone 
reproduce the crash?

Christoph

Re: [matplotlib-devel] Delaying rc3 (again)

[Russell E. O. <ro...@uw...>]

In article <508...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:

> Agreed!  Thanks to everyone for their hard work.  I think this has 
> shaped up to be a great release.
> 
> I'm fortunate to have power and connectivity today, so I was able to get 
> a release tested, tagged and uploaded.
> 
> To our binary builders: as able, it would be great to put the binaries 
> up (or send them to me to do so), and then I'll make an announcement on 
> matplotlib-users.  I really intend (barring any really serious issues) 
> this to be the last rc before the 1.2.0 final.
> 
> Thanks again,
> Mike

The Mac binaries are now up. This time it built perfectly on MacOS X 
10.4; thanks to the folks that worked so hard fixing those build 
problems.

The 32-bit version is not well tested because I have neither inkscape 
nor ghostscript installed on that ancient system, but it passes the 
tests that it can run under those circumstances.

The 64-bit version passes all tests except 2 knownfail and 3 skipped.

-- Russell

P.S. I had to build the 64-bit version twice. The first time I tried to 
build it using the same directory of code that I used to build 32-bit 
version. I first deleted the "build" and "dist" subdirectories and ran 
"python setup.py clean", then built as usual. There were no errors or 
warnings during the build, but the unit tests would not run on the 
results -- complaining of missing modules.

So I built again using a freshly unpacked code directory and that worked 
just fine.

I'm pretty sure I've seen this problem before, but keep forgetting to 
ask about it.

Is this a bug somewhere (e.g. in matplotlib's setup.py or somewhere in 
python) or is there some better way to clear out a python code directory?

Re: [matplotlib-devel] Delaying rc3 (again)

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

Agreed!  Thanks to everyone for their hard work.  I think this has 
shaped up to be a great release.

I'm fortunate to have power and connectivity today, so I was able to get 
a release tested, tagged and uploaded.

To our binary builders: as able, it would be great to put the binaries 
up (or send them to me to do so), and then I'll make an announcement on 
matplotlib-users.  I really intend (barring any really serious issues) 
this to be the last rc before the 1.2.0 final.

Thanks again,
Mike

On 10/30/2012 11:28 AM, Phil Elson wrote:
> > Given the severe weather approaching this area, I
> won't have a chance to test and get out an 1.2.0rc3 candidate until at
> least Thursday.
>
> Very pleased to see that you have weathered the storm and are back 
> githubbing!
>
> There are no more PRs in the 1.2.x milestone 
> (https://github.com/matplotlib/matplotlib/issues?milestone=4&page=1&state=open) 
> so I think we are in a good state to take a cut at any point.
> I would be happy enough to spend the afternoon preparing a release 
> candidate 3 (though other than tagging and running tests on as many 
> architectures as possible, I'm not familiar with what is involved) if 
> that would help? If you would rather wait, I don't think it is a big 
> problem, the important thing to know is that we are on firm ground and 
> the v1.2.x branch is in a fantastic state for release.
>
> To everyone who has helped us with testing or bug finding/squashing 
> for this release so far: Thank you for your hard work and commitment - 
> it really does make the release so much better as a result.
>
> All the best,
>
> Phil
>
>
>
>
>
>
>
> On 29 October 2012 19:10, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     Just a quick note: Given the severe weather approaching this area, I
>     won't have a chance to test and get out an 1.2.0rc3 candidate until at
>     least Thursday.
>
>     Mike
>
>     ------------------------------------------------------------------------------
>     The Windows 8 Center - In partnership with Sourceforge
>     Your idea - your app - 30 days.
>     Get started!
>     http://windows8center.sourceforge.net/
>     what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Delaying rc3 (again)

[Phil E. <pel...@gm...>]

> Given the severe weather approaching this area, I
won't have a chance to test and get out an 1.2.0rc3 candidate until at
least Thursday.

Very pleased to see that you have weathered the storm and are back
githubbing!

There are no more PRs in the 1.2.x milestone (
https://github.com/matplotlib/matplotlib/issues?milestone=4&page=1&state=open)
so I think we are in a good state to take a cut at any point.
I would be happy enough to spend the afternoon preparing a release
candidate 3 (though other than tagging and running tests on as many
architectures as possible, I'm not familiar with what is involved) if that
would help? If you would rather wait, I don't think it is a big problem,
the important thing to know is that we are on firm ground and the v1.2.x
branch is in a fantastic state for release.

To everyone who has helped us with testing or bug finding/squashing for
this release so far: Thank you for your hard work and commitment - it
really does make the release so much better as a result.

All the best,

Phil







On 29 October 2012 19:10, Michael Droettboom <md...@st...> wrote:

> Just a quick note: Given the severe weather approaching this area, I
> won't have a chance to test and get out an 1.2.0rc3 candidate until at
> least Thursday.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[Nicolas R. <Nic...@in...>]

Yep, I can confirm this but the story is a bit different on my side since the .png is wrong but not the .pdf (only ok with Acrobat Reader though):

import numpy as np
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt

n = 16
fig = plt.figure(figsize=(6,6))
Z = np.zeros((n,n))
Z[::2,::2] = Z[1::2,1::2] = 1
plt.imshow(Z, interpolation='none', cmap=plt.cm.gray, extent=[0,n,0,n], alpha=0.25)
plt.xticks(np.arange(0,n), []), plt.yticks(np.arange(0,n), [])
plt.grid(ls='solid')
delta = 0.01
plt.xlim(1-delta,1+delta), plt.ylim(1-delta,1+delta)
plt.savefig('pylab-grid.png')
plt.savefig('pylab-grid.pdf')


Nicolas




On Oct 30, 2012, at 10:59 , Maciek Dems wrote:

> In reply to message from Nicolas Rougier, dated Tuesday 30 of October 2012, 
> on subject "Re: [matplotlib-devel] Misalignment imshow vs. grid lines"
> > You're right. Using 'none' interpolation seems to solve the problem. Good
> > to know !
>  
> Unfortunately it does not! It only makes problem less pronounced, but still present. Furthermore pcolor is also affected, similarly to imshow, however, the misalignment is usually no more than one pixel (although in some applications it is still unacceptable).
>  
> I guess that the problem is with truncation errors in some calculations...
>  
> Here are some test scripts and sample results. Mind that the misalignment depend randomly on zoom factor and the position of the image.
>  
> The scripts:
>  
> # test_imshow.py
> # --------------
> import numpy as np
> import matplotlib.pyplot as plt
>  
> n = 16
> fig = plt.figure(figsize=(10,10))
>  
> Z = np.ones((n, n))
> Z[::2, ::2] = 2
> Z[1::2, 1::2] = 2
>  
> def test(interp, sub):
>     plt.subplot(sub)
>     
>     plt.imshow(Z, interpolation=interp,
>                     cmap='gray', extent=[0, n, 0, n], vmin=0)
>  
>     plt.xticks(np.arange(n))
>     plt.yticks(np.arange(n))
>     plt.grid(ls='solid')
>     plt.title(interp)
>  
> test('nearest', 121)
> test('none', 122)
>  
> plt.show()
>  
>  
>  
> # test_pcolor.py
> # --------------
> import numpy as np
> import matplotlib.pyplot as plt
>  
> n = 16
> fig = plt.figure(figsize=(10,10))
>  
> Z = np.ones((n, n))
> Z[::2, ::2] = 2
> Z[1::2, 1::2] = 2
>  
> plt.pcolor(np.arange(n+1), np.arange(n+1), Z,
>             cmap='gray', vmin=0)
>  
> plt.xticks(np.arange(n))
> plt.yticks(np.arange(n))
> plt.grid(ls='solid')
>  
> plt.show()
>  
>  
>  
> The results (some manual zooming) are attached and also available here:
> http://dems.art.pl/files/imshow.png
> http://dems.art.pl/files/pcolor.png
>  
> -- 
> Maciek Dems                             http://dems.art.pl/en
> <pcolor.png><imshow.png>------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[Phil E. <pel...@gm...>]

Thanks for making this so easy to reproduce. It is so much easier when
there is a small, self contained, correct example!

Initially I was thinking that the problem was some kind of snapping issue
with the ticks, but it turns out, if you change the interpolation scheme to
"none", you get perfect alignment:


import numpy as np
import matplotlib.pyplot as plt

n = 16
fig = plt.figure(figsize=(10,10))

Z = np.zeros((n, n))
Z[::2, ::2] = 1
Z[1::2, 1::2] = 1

# pick the interpolation you want:
interp = 'nearest'
interp = 'none'

plt.imshow(Z, interpolation=interp,
                cmap='gray', extent=[0, n, 0, n],
                alpha=0.25)

plt.xticks(np.arange(n))
plt.yticks(np.arange(n))
plt.grid(ls='solid')

plt.show()



I haven't considered where to go from this point, but I wanted to let you
know about this option.

Thanks,

Phil



On 30 October 2012 07:10, Nicolas Rougier <Nic...@in...> wrote:

>
>
> Sorry, I was too fast in my reply.
>
> When I save the figure, the png output is ok while the pdf is displaying
> some kind of interpolation with the image.
>
> import numpy as np
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
>
> n = 16
> fig = plt.figure(figsize=(6,6))
> Z = np.array(([0,1]*(n//2) + [1,0]*(n//2))*(n//2)).reshape(n,n)
> plt.imshow(Z, interpolation='none', cmap=plt.cm.gray, extent=[0,n,0,n],
> alpha=.25)
> plt.xticks(np.arange(0,n), [])
> plt.yticks(np.arange(0,n), [])
> plt.grid(ls='solid')
> plt.savefig('pylab-grid.png')
> plt.savefig('pylab-grid.pdf')
> plt.show()
>
>
>
>
>
> Just for the record, "Skim", "Preview" and "Adobe Reader" on OSX do not
> give the same output on the saved pdf.
> "Adobe Reader" displays the expected result (same as saved png) while
> "Preview" and "Skim" are apparently trying to make some (bad) interpolation
> of the checkboard image.
>
>
> Nicolas
>
>
> On Oct 30, 2012, at 7:52 , Nicolas Rougier wrote:
>
> >
> >
> > You're right. Using 'none' interpolation seems to solve the problem.
> Good to know !
> >
> > One last question, why is the 'none' interpolation restricted to
> Agg/PS/pdf ?
> >
> >
> > Nicolas
> >
> >
> >
> > On Oct 30, 2012, at 6:53 , Jae-Joon Lee wrote:
> >
> >> On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier
> >> <Nic...@in...> wrote:
> >>>
> >>>
> >>> Thanks for testing.
> >>>
> >>> If I zoom at any line cross, the lines are definitely at the wrong
> place for me.
> >>
> >> As  jules hummon commented, I see lines in right places when I zoom in.
> >>
> >>> As for screen aliasing I'm not sure since both the png and pdf seems
> to be wrong in my case.
> >>
> >> It still can be some aliasing-related issue. Note that with
> >> interpolation="nearest", the images are rasterized with given dpi even
> >> if you save the figure as pdf.
> >> The agg backend tries to adjust the location of lines and images so
> >> that they are well-aligned with the pixels, and the issue seems to be
> >> related with that behavior.
> >>
> >> In my case, using interpolation="none" worked out okay. So give it a
> try.
> >>
> >> Regards,
> >>
> >> -JJ
> >>
> >>
> >>> Weird !
> >>>
> >>>
> >>> Nicolas
> >>>
> >>>
> >>> On Oct 29, 2012, at 15:40 , jules hummon wrote:
> >>>
> >>>> Nicolas
> >>>>
> >>>> I get that too, (with your script and various things in my work).
> >>>> But if you zoom in, the lines are in the right place.   Is it
> >>>> some kind of screen aliasing?
> >>>>
> >>>> Jules
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> The Windows 8 Center - In partnership with Sourceforge
> >>>> Your idea - your app - 30 days.
> >>>> Get started!
> >>>> http://windows8center.sourceforge.net/
> >>>>
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> >>>> _______________________________________________
> >>>> Matplotlib-devel mailing list
> >>>> Mat...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> The Windows 8 Center - In partnership with Sourceforge
> >>> Your idea - your app - 30 days.
> >>> Get started!
> >>> http://windows8center.sourceforge.net/
> >>>
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[Nicolas R. <Nic...@in...>]

Sorry, I was too fast in my reply.

When I save the figure, the png output is ok while the pdf is displaying some kind of interpolation with the image.

import numpy as np
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt

n = 16
fig = plt.figure(figsize=(6,6))
Z = np.array(([0,1]*(n//2) + [1,0]*(n//2))*(n//2)).reshape(n,n)
plt.imshow(Z, interpolation='none', cmap=plt.cm.gray, extent=[0,n,0,n], alpha=.25)
plt.xticks(np.arange(0,n), [])
plt.yticks(np.arange(0,n), [])
plt.grid(ls='solid')
plt.savefig('pylab-grid.png')
plt.savefig('pylab-grid.pdf')
plt.show()





Just for the record, "Skim", "Preview" and "Adobe Reader" on OSX do not give the same output on the saved pdf.
"Adobe Reader" displays the expected result (same as saved png) while "Preview" and "Skim" are apparently trying to make some (bad) interpolation of the checkboard image.


Nicolas


On Oct 30, 2012, at 7:52 , Nicolas Rougier wrote:

> 
> 
> You're right. Using 'none' interpolation seems to solve the problem. Good to know !
> 
> One last question, why is the 'none' interpolation restricted to Agg/PS/pdf ?
> 
> 
> Nicolas
> 
> 
> 
> On Oct 30, 2012, at 6:53 , Jae-Joon Lee wrote:
> 
>> On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier
>> <Nic...@in...> wrote:
>>> 
>>> 
>>> Thanks for testing.
>>> 
>>> If I zoom at any line cross, the lines are definitely at the wrong place for me.
>> 
>> As  jules hummon commented, I see lines in right places when I zoom in.
>> 
>>> As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case.
>> 
>> It still can be some aliasing-related issue. Note that with
>> interpolation="nearest", the images are rasterized with given dpi even
>> if you save the figure as pdf.
>> The agg backend tries to adjust the location of lines and images so
>> that they are well-aligned with the pixels, and the issue seems to be
>> related with that behavior.
>> 
>> In my case, using interpolation="none" worked out okay. So give it a try.
>> 
>> Regards,
>> 
>> -JJ
>> 
>> 
>>> Weird !
>>> 
>>> 
>>> Nicolas
>>> 
>>> 
>>> On Oct 29, 2012, at 15:40 , jules hummon wrote:
>>> 
>>>> Nicolas
>>>> 
>>>> I get that too, (with your script and various things in my work).
>>>> But if you zoom in, the lines are in the right place.   Is it
>>>> some kind of screen aliasing?
>>>> 
>>>> Jules
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> The Windows 8 Center - In partnership with Sourceforge
>>>> Your idea - your app - 30 days.
>>>> Get started!
>>>> http://windows8center.sourceforge.net/
>>>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> The Windows 8 Center - In partnership with Sourceforge
>>> Your idea - your app - 30 days.
>>> Get started!
>>> http://windows8center.sourceforge.net/
>>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[Nicolas R. <Nic...@in...>]

You're right. Using 'none' interpolation seems to solve the problem. Good to know !

One last question, why is the 'none' interpolation restricted to Agg/PS/pdf ?


Nicolas



On Oct 30, 2012, at 6:53 , Jae-Joon Lee wrote:

> On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier
> <Nic...@in...> wrote:
>> 
>> 
>> Thanks for testing.
>> 
>> If I zoom at any line cross, the lines are definitely at the wrong place for me.
> 
> As  jules hummon commented, I see lines in right places when I zoom in.
> 
>> As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case.
> 
> It still can be some aliasing-related issue. Note that with
> interpolation="nearest", the images are rasterized with given dpi even
> if you save the figure as pdf.
> The agg backend tries to adjust the location of lines and images so
> that they are well-aligned with the pixels, and the issue seems to be
> related with that behavior.
> 
> In my case, using interpolation="none" worked out okay. So give it a try.
> 
> Regards,
> 
> -JJ
> 
> 
>> Weird !
>> 
>> 
>> Nicolas
>> 
>> 
>> On Oct 29, 2012, at 15:40 , jules hummon wrote:
>> 
>>> Nicolas
>>> 
>>> I get that too, (with your script and various things in my work).
>>> But if you zoom in, the lines are in the right place.   Is it
>>> some kind of screen aliasing?
>>> 
>>> Jules
>>> 
>>> ------------------------------------------------------------------------------
>>> The Windows 8 Center - In partnership with Sourceforge
>>> Your idea - your app - 30 days.
>>> Get started!
>>> http://windows8center.sourceforge.net/
>>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> The Windows 8 Center - In partnership with Sourceforge
>> Your idea - your app - 30 days.
>> Get started!
>> http://windows8center.sourceforge.net/
>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

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

On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier
<Nic...@in...> wrote:
>
>
> Thanks for testing.
>
> If I zoom at any line cross, the lines are definitely at the wrong place for me.

As  jules hummon commented, I see lines in right places when I zoom in.

> As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case.

It still can be some aliasing-related issue. Note that with
interpolation="nearest", the images are rasterized with given dpi even
if you save the figure as pdf.
The agg backend tries to adjust the location of lines and images so
that they are well-aligned with the pixels, and the issue seems to be
related with that behavior.

In my case, using interpolation="none" worked out okay. So give it a try.

Regards,

-JJ


> Weird !
>
>
> Nicolas
>
>
> On Oct 29, 2012, at 15:40 , jules hummon wrote:
>
>> Nicolas
>>
>> I get that too, (with your script and various things in my work).
>> But if you zoom in, the lines are in the right place.   Is it
>> some kind of screen aliasing?
>>
>> Jules
>>
>> ------------------------------------------------------------------------------
>> The Windows 8 Center - In partnership with Sourceforge
>> Your idea - your app - 30 days.
>> Get started!
>> http://windows8center.sourceforge.net/
>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[gary r. <gr...@bi...>]

I also see this in mpl 1.1.0, python 2.7.2 with the iPython Qt console
and also with the WXAgg backend

Gary R.

On 30 October 2012 03:16, Nicolas Rougier <Nic...@in...> wrote:
>
>
> matplotlib 1.2.x
> python     2.7.2
> osx        10.7.5
>
>
> Nicolas
>
> On Oct 29, 2012, at 16:29 , Benjamin Root wrote:
>
>>
>>
>> On Mon, Oct 29, 2012 at 11:25 AM, Nicolas Rougier <Nic...@in...> wrote:
>>
>>
>> Thanks for testing.
>>
>> If I zoom at any line cross, the lines are definitely at the wrong place for me.
>> As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case.
>> Weird !
>>
>>
>>
>> Which version of matplotlib are you using, just for reference.
>>
>> Ben Root
>>
>
>
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Delaying rc3 (again)

[Jeff W. <jef...@no...>]

On 10/29/12 1:10 PM, Michael Droettboom wrote:
> Just a quick note: Given the severe weather approaching this area, I
> won't have a chance to test and get out an 1.2.0rc3 candidate until at
> least Thursday.
>
> Mike
>
Mike:

While you're hunkered down waiting the storm out, you can check out some 
experimental forecast graphics created using matplotlib and basemap

http://www.hfip.org/data_ens/

(if you have internet access, that is).  Be safe!

-Jeff


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

[matplotlib-devel] Delaying rc3 (again)

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

Just a quick note: Given the severe weather approaching this area, I 
won't have a chance to test and get out an 1.2.0rc3 candidate until at 
least Thursday.

Mike

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[Nicolas R. <Nic...@in...>]

matplotlib 1.2.x
python     2.7.2
osx        10.7.5


Nicolas

On Oct 29, 2012, at 16:29 , Benjamin Root wrote:

> 
> 
> On Mon, Oct 29, 2012 at 11:25 AM, Nicolas Rougier <Nic...@in...> wrote:
> 
> 
> Thanks for testing.
> 
> If I zoom at any line cross, the lines are definitely at the wrong place for me.
> As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case.
> Weird !
> 
> 
> 
> Which version of matplotlib are you using, just for reference.
> 
> Ben Root
> 

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

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

On Mon, Oct 29, 2012 at 11:25 AM, Nicolas Rougier
<Nic...@in...>wrote:

>
>
> Thanks for testing.
>
> If I zoom at any line cross, the lines are definitely at the wrong place
> for me.
> As for screen aliasing I'm not sure since both the png and pdf seems to be
> wrong in my case.
> Weird !
>
>
>
Which version of matplotlib are you using, just for reference.

Ben Root

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[Nicolas R. <Nic...@in...>]

Thanks for testing.

If I zoom at any line cross, the lines are definitely at the wrong place for me.
As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case.
Weird !


Nicolas


On Oct 29, 2012, at 15:40 , jules hummon wrote:

> Nicolas
> 
> I get that too, (with your script and various things in my work).
> But if you zoom in, the lines are in the right place.   Is it
> some kind of screen aliasing?
> 
> Jules
> 
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Test Failure: AttributeError: incompatible shape for a non-contiguous array

[Patrick M. <pat...@gm...>]

Just a follow up for historical sake:

This is a bug in numpy and was introduced in this commit:
https://github.com/numpy/numpy/commit/c48156dfdc408f0a1e59ef54ac490cccbd6b8d73

I've filed a ticket with Numpy and those interested can follow up here:
https://github.com/numpy/numpy/issues/2700


PTM

---
Patrick Marsh
Ph.D. Candidate / Liaison to the HWT
School of Meteorology / University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
National Severe Storms Laboratory
http://www.patricktmarsh.com



On Mon, Oct 29, 2012 at 8:46 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Mon, Oct 29, 2012 at 9:16 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Mon, Oct 29, 2012 at 1:51 AM, Patrick Marsh <pat...@gm...>wrote:
>>
>>> Greetings,
>>>
>>> I've banged my head against this problem for 2 days and have given up on
>>> figuring it out on my own…
>>>
>>> After updating numpy and matplotlib to the latest versions from github
>>> Saturday morning, I keep getting "AttributeError: incompatible shape for a
>>> non-contiguous array" errors all over the place when plotting. When I run
>>> tests on numpy, everything passes. When I run tests on matplotlib, I get 51
>>> errors, with a vast majority of them (possibly all) being the
>>> non-contiguous array errors. (Sample below)
>>>
>>> Any suggestions here? I'm totally stumped.
>>>
>>>
>>> PTM
>>>
>>>
>>>
>> I am guessing this is a problem introduced with NumPy.  I just tried the
>> tests with an older NumPy branch, and all seemed fine.  Now testing with
>> the most recent branch.
>>
>> Ben Root
>>
>
> Confirming the bug (and it appears to be happening at a spot that I
> updated a couple years ago to catch exactly these sort of situations where
> reshaping would result in a copy when we didn't want a copy).
>
> I am presuming that it is a NumPy bug and will report it as such to the
> numpy list.
>
> Cheers!
> Ben Root
>
>

Re: [matplotlib-devel] Misalignment imshow vs. grid lines

[jules h. <hu...@ha...>]

Nicolas

I get that too, (with your script and various things in my work).
But if you zoom in, the lines are in the right place.   Is it
some kind of screen aliasing?

Jules

[matplotlib-devel] Misalignment imshow vs. grid lines

[Nicolas R. <Nic...@in...>]

Hi,

I tried to plot a grid over a small image (24x24) and some grid lines are mis-aligned, can anybody confirm the behavior ?

Here is a sample script:

import numpy as np
import matplotlib.pyplot as plt

n = 16
fig = plt.figure(figsize=(10,10))
Z = np.array(([0,1]*(n//2) + [1,0]*(n//2))*(n//2)).reshape(n,n)
plt.imshow(Z, interpolation='nearest', cmap=plt.cm.gray, extent=[0,n,0,n], alpha=.25)
plt.xticks(np.arange(0,n), [])
plt.yticks(np.arange(0,n), [])
plt.grid(ls='solid')
plt.show()


Here is a sample output (it's worse on screen):




Nicolas

Re: [matplotlib-devel] Test Failure: AttributeError: incompatible shape for a non-contiguous array

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

On Mon, Oct 29, 2012 at 9:16 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Mon, Oct 29, 2012 at 1:51 AM, Patrick Marsh <pat...@gm...>wrote:
>
>> Greetings,
>>
>> I've banged my head against this problem for 2 days and have given up on
>> figuring it out on my own…
>>
>> After updating numpy and matplotlib to the latest versions from github
>> Saturday morning, I keep getting "AttributeError: incompatible shape for a
>> non-contiguous array" errors all over the place when plotting. When I run
>> tests on numpy, everything passes. When I run tests on matplotlib, I get 51
>> errors, with a vast majority of them (possibly all) being the
>> non-contiguous array errors. (Sample below)
>>
>> Any suggestions here? I'm totally stumped.
>>
>>
>> PTM
>>
>>
>>
> I am guessing this is a problem introduced with NumPy.  I just tried the
> tests with an older NumPy branch, and all seemed fine.  Now testing with
> the most recent branch.
>
> Ben Root
>

Confirming the bug (and it appears to be happening at a spot that I updated
a couple years ago to catch exactly these sort of situations where
reshaping would result in a copy when we didn't want a copy).

I am presuming that it is a NumPy bug and will report it as such to the
numpy list.

Cheers!
Ben Root

Re: [matplotlib-devel] Test Failure: AttributeError: incompatible shape for a non-contiguous array

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

On Mon, Oct 29, 2012 at 1:51 AM, Patrick Marsh <pat...@gm...>wrote:

> Greetings,
>
> I've banged my head against this problem for 2 days and have given up on
> figuring it out on my own…
>
> After updating numpy and matplotlib to the latest versions from github
> Saturday morning, I keep getting "AttributeError: incompatible shape for a
> non-contiguous array" errors all over the place when plotting. When I run
> tests on numpy, everything passes. When I run tests on matplotlib, I get 51
> errors, with a vast majority of them (possibly all) being the
> non-contiguous array errors. (Sample below)
>
> Any suggestions here? I'm totally stumped.
>
>
> PTM
>
>
>
I am guessing this is a problem introduced with NumPy.  I just tried the
tests with an older NumPy branch, and all seemed fine.  Now testing with
the most recent branch.

Ben Root

Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)

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

Hi Geoffroy

This will certainly be very useful.  I need to spend some time looking at
it and seeing how it would best fit within the matplotlib framework,
particularly as only a few days ago I committed to writing a triangular
grid interpolator for quad grids and it would be sensible to group these
interpolators together in some way.

I'll get back to you when I've had time to look at it.

Thanks for your efforts!
Ian


On 28 October 2012 20:17, GBillotey <geo...@gm...> wrote:

>    Hi!
>
>
> I had recently to develop interpolators for a function defined at the nodes
> of a user-specified triangular mesh.
> (Beside interpolation, it can help producing higher-quality tricontour
> plots, using interpolation on a refined mesh and matplotlib tricontour
> function.)
>
> Being a regular user of matplotlib, I would be happy if it can be useful to
> others...
> The code is hosted here:
> https://github.com/GBillotey/trimesh-interpolator.git
>
>
> Please let me know if it this dev. can be useful and if the code needs some
> cleaning (I am not a computer scientist, only a mechanical engineer)
>
>
> Cheers,
> Geoffroy.
>