matplotlib-devel Mailing List for matplotlib

Awesome, many thanks for the detailed instructions, as well as for the
valuable suggestions by Eric and Jens. I have now created a pull
request containing the proposed change, including the suggested
modifications:
 https://github.com/matplotlib/matplotlib/pull/1442
Any comments/feedback would be much appreciated.
Best wishes,
Max
2012年10月31日 Damon McDougall <dam...@gm...>:
> On Wed, Oct 31, 2012 at 7:40 AM, Maximilian Albert
> <max...@gm...> wrote:
>> 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.
>
> You need to fork the main matplotlib repo, so you have your own copy
> associated with your github account:
> https://help.github.com/articles/fork-a-repo
>
> Once you've forked it, clone it and create a branch:
>
> git clone my-forked-repo-url
> cd matplotlib
> git checkout -b my_awesome_new_feature
> # ... hack hack hack ...
> git commit -am "Useful commit message here"
> git push origin my_awesome_new_feature
>
> Once you've done that, make a pull request by following the
> instructions here:
> https://help.github.com/articles/using-pull-requests
>
> Once you've done that, congratulations!
>
> Hope this helps.
> 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

I confirm on 1.2.x. on OSX 10.7.5.
Nicolas
On Oct 31, 2012, at 17:20 , Andrew Dawson wrote:
> Hi all,
> 
> I just noticed that colorbar edges are drawn in white when output in PDF and black when output in PNG. A small test script is attached along with the output to show the difference.
> 
> I'd be interested in knowing if others can reproduce this? I'm using mpl-1.3.x (updated 5 minutes ago) on 64-bit Ubuntu 12.04.
> 
> Cheers,
> Andrew
> <bug.py><test.png><test.pdf>------------------------------------------------------------------------------
> 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

I think Eric idea is a good solution. This is just to point out that I did
something similar
with kw args to savefig in the image comparison decorator for tests. See
the changes in
decorators.py in this pull request
https://github.com/matplotlib/matplotlib/pull/1420 . Seems to work fine.
Greetings, Jens
On Wed, Oct 31, 2012 at 4:22 PM, Eric Firing <ef...@ha...> wrote:
> On 2012年10月31日 2:04 AM, Maximilian Albert 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.
>
> I don't have time to look at this, so I will toss out one idea for
> consideration:
>
> If there is any chance that other sorts of kwarg collections might be
> needed, or simply to improve readability and explicitness, instead of
> passing on **kwargs, you might make a new kwarg, "savefigkw", which
> would take a dictionary that would then be used via "savefig(...,
> **savefigkw".
>
> Eric
>
>
> >
> > Many thanks and kind regards,
> > Max
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>

On 2012年10月31日 2:04 AM, Maximilian Albert 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.
I don't have time to look at this, so I will toss out one idea for 
consideration:
If there is any chance that other sorts of kwarg collections might be 
needed, or simply to improve readability and explicitness, instead of 
passing on **kwargs, you might make a new kwarg, "savefigkw", which 
would take a dictionary that would then be used via "savefig(..., 
**savefigkw".
Eric
>
> Many thanks and kind regards,
> Max
>
>
>
> ------------------------------------------------------------------------------
> 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
>

On Wed, Oct 31, 2012 at 7:40 AM, Maximilian Albert
<max...@gm...> wrote:
> 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.
You need to fork the main matplotlib repo, so you have your own copy
associated with your github account:
https://help.github.com/articles/fork-a-repo
Once you've forked it, clone it and create a branch:
git clone my-forked-repo-url
cd matplotlib
git checkout -b my_awesome_new_feature
# ... hack hack hack ...
git commit -am "Useful commit message here"
git push origin my_awesome_new_feature
Once you've done that, make a pull request by following the
instructions here:
https://help.github.com/articles/using-pull-requests
Once you've done that, congratulations!
Hope this helps.
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

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

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

[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

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

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

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?

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

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

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

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
>

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

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

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

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

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

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

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
> 

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

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

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