matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] dead link on matplotlib.org page

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

It's actually better to create these issues against the main matplotlib 
repository since all of the bugs are fixed over there in the source.  
matplotlib.github.com only contains generated files.

Mike

On 11/08/2012 11:50 AM, Phil Elson wrote:
> To raise (built) documentation based problems, I have been creating 
> issues in https://github.com/matplotlib/matplotlib.github.com .
> That seems to work well, but sadly, it always seems to be Michael that 
> ends up sorting it out... he is a victim of his own success (and 
> speed) ;-)
>
>
> On 8 November 2012 16:31, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
>     And I had completely missed that this was taken care of
>     yesterday.  However, the changelog link from the what's new page
>     is still dead.
>
>     Ben
>
>
>     On Thu, Nov 8, 2012 at 11:24 AM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>
>         There is a link to the CHANGELOG (are we even keeping that up
>         to date anymore?) on the main page that is dead.
>
>         Ben Root
>
>
>
>     ------------------------------------------------------------------------------
>     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_d2d_nov
>     _______________________________________________
>     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_d2d_nov
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] dead link on matplotlib.org page

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

To raise (built) documentation based problems, I have been creating issues
in https://github.com/matplotlib/matplotlib.github.com .
That seems to work well, but sadly, it always seems to be Michael that ends
up sorting it out... he is a victim of his own success (and speed) ;-)


On 8 November 2012 16:31, Benjamin Root <ben...@ou...> wrote:

> And I had completely missed that this was taken care of yesterday.
> However, the changelog link from the what's new page is still dead.
>
> Ben
>
>
> On Thu, Nov 8, 2012 at 11:24 AM, Benjamin Root <ben...@ou...> wrote:
>
>> There is a link to the CHANGELOG (are we even keeping that up to date
>> anymore?) on the main page that is dead.
>>
>> Ben Root
>>
>
>
>
> ------------------------------------------------------------------------------
> 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_d2d_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] dead link on matplotlib.org page

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

And I had completely missed that this was taken care of yesterday.
However, the changelog link from the what's new page is still dead.

Ben

On Thu, Nov 8, 2012 at 11:24 AM, Benjamin Root <ben...@ou...> wrote:

> There is a link to the CHANGELOG (are we even keeping that up to date
> anymore?) on the main page that is dead.
>
> Ben Root
>

[matplotlib-devel] dead link on matplotlib.org page

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

There is a link to the CHANGELOG (are we even keeping that up to date
anymore?) on the main page that is dead.

Ben Root

Re: [matplotlib-devel] Last call for 1.2.0

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

See

https://github.com/matplotlib/matplotlib/pull/1463

Mike

On 11/08/2012 03:06 AM, Jens Nielsen wrote:
>
> I just noticed a small documentation issue yesterday.  This table does 
> not include the
> gtk3 backend 
> http://matplotlib.org/1.2.0/faq/usage_faq.html#what-is-a-backend
>
> Should we update the table to include the gtk3 backend? (and note that 
> the qt3 backend is depreciated)
>
> Jens
>
>
>
> On Thu, Nov 8, 2012 at 3:23 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     The milestone is clear.  Is there anything we're missing?
>
>     If not, I plan to cut a final release and update the documentation
>     website tomorrow morning.
>
>     Mike
>
>     ------------------------------------------------------------------------------
>     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_d2d_nov
>     _______________________________________________
>     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_d2d_nov
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Last call for 1.2.0

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

While I think Paul's contribution in #1462 is great, I'd prefer to not 
put this in 1.2.0.  There just isn't enough time to review such a large 
patch this late in the game.  As our experience with Nelle's valuable 
PEP8 work shows, it's still possible to slip in accidental breakage even 
when making mostly mechanical changes.  I'm fine with it going on the 
1.2.x branch after the release, however, so it would be in 1.2.1 (if we 
do one), so there's no need to change the PR target etc. at this point 
-- I'll just add a note that we don't want it to be merged until after 
1.2.0 has been tagged.

Mike

On 11/08/2012 05:38 AM, Phil Elson wrote:
> Just closed the PR which proposes this change against master (in 
> favour of the one against v1.2.x).
>
> It is very late in the day to be making so many example changes 
> (especially as we don't have tests for them).
> Personally, the balance between the risks vs the benefits doesn't give 
> me much indication of which way to go (I guess that is partly because 
> I don't actually prefer the plt.subplots() interface in some 
> situations). I guess that is a debate for inside the PR 
> (https://github.com/matplotlib/matplotlib/pull/1462).
>
> Cheers,
>
>
>
>
> On 8 November 2012 09:22, Paul Ivanov <piv...@gm... 
> <mailto:piv...@gm...>> wrote:
>
>     On Wed, Nov 7, 2012 at 6:23 PM, Michael Droettboom
>     <md...@st... <mailto:md...@st...>> wrote:
>     > The milestone is clear.  Is there anything we're missing?
>     >
>     > If not, I plan to cut a final release and update the documentation
>     > website tomorrow morning.
>
>     I just submitted #1462 against v1.2.x, (which is also pending as #1458
>     against master).
>
>     "use plt.subplots() in examples as much as possible"
>
>     replaces a whole bunch of example code like this:
>
>         fig = plt.figure()
>         ax = plt.subplot(111) # or plt.add_subplot(111)
>
>     to be just this:
>
>         fig, ax = plt.subplots()
>
>     This is a docs-only update - but I think it'll be worthwhile to start
>     to give a more sensible way of creating figures and axes in one call
>     for our the folks who'll be looking at matplotlib with fresh eyes
>     after the 1.2 release.
>
>     But I totally understand if folks feel this is too big of a pill to
>     swallow this late in the game.
>
>     go, team, go!
>     --
>     Paul Ivanov
>     314 address only used for lists,  off-list direct email at:
>     http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>     ------------------------------------------------------------------------------
>     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_d2d_nov
>     _______________________________________________
>     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_d2d_nov
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Last call for 1.2.0

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

Just closed the PR which proposes this change against master (in favour of
the one against v1.2.x).

It is very late in the day to be making so many example changes (especially
as we don't have tests for them).
Personally, the balance between the risks vs the benefits doesn't give me
much indication of which way to go (I guess that is partly because I don't
actually prefer the plt.subplots() interface in some situations). I guess
that is a debate for inside the PR (
https://github.com/matplotlib/matplotlib/pull/1462).

Cheers,




On 8 November 2012 09:22, Paul Ivanov <piv...@gm...> wrote:

> On Wed, Nov 7, 2012 at 6:23 PM, Michael Droettboom <md...@st...>
> wrote:
> > The milestone is clear.  Is there anything we're missing?
> >
> > If not, I plan to cut a final release and update the documentation
> > website tomorrow morning.
>
> I just submitted #1462 against v1.2.x, (which is also pending as #1458
> against master).
>
> "use plt.subplots() in examples as much as possible"
>
> replaces a whole bunch of example code like this:
>
>     fig = plt.figure()
>     ax = plt.subplot(111) # or plt.add_subplot(111)
>
> to be just this:
>
>     fig, ax = plt.subplots()
>
> This is a docs-only update - but I think it'll be worthwhile to start
> to give a more sensible way of creating figures and axes in one call
> for our the folks who'll be looking at matplotlib with fresh eyes
> after the 1.2 release.
>
> But I totally understand if folks feel this is too big of a pill to
> swallow this late in the game.
>
> go, team, go!
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
> ------------------------------------------------------------------------------
> 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_d2d_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Last call for 1.2.0

[Paul I. <piv...@gm...>]

On Wed, Nov 7, 2012 at 6:23 PM, Michael Droettboom <md...@st...> wrote:
> The milestone is clear.  Is there anything we're missing?
>
> If not, I plan to cut a final release and update the documentation
> website tomorrow morning.

I just submitted #1462 against v1.2.x, (which is also pending as #1458
against master).

"use plt.subplots() in examples as much as possible"

replaces a whole bunch of example code like this:

    fig = plt.figure()
    ax = plt.subplot(111) # or plt.add_subplot(111)

to be just this:

    fig, ax = plt.subplots()

This is a docs-only update - but I think it'll be worthwhile to start
to give a more sensible way of creating figures and axes in one call
for our the folks who'll be looking at matplotlib with fresh eyes
after the 1.2 release.

But I totally understand if folks feel this is too big of a pill to
swallow this late in the game.

go, team, go!
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Re: [matplotlib-devel] Last call for 1.2.0

[Jens N. <jen...@gm...>]

I just noticed a small documentation issue yesterday.  This table does not
include the
gtk3 backend
http://matplotlib.org/1.2.0/faq/usage_faq.html#what-is-a-backend

Should we update the table to include the gtk3 backend? (and note that the
qt3 backend is depreciated)

Jens



On Thu, Nov 8, 2012 at 3:23 AM, Michael Droettboom <md...@st...> wrote:

> The milestone is clear.  Is there anything we're missing?
>
> If not, I plan to cut a final release and update the documentation
> website tomorrow morning.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> 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_d2d_nov
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Last call for 1.2.0

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

The milestone is clear.  Is there anything we're missing?

If not, I plan to cut a final release and update the documentation 
website tomorrow morning.

Mike

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

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

P.S.: As an aside, when I run ffmpeg on my machine it issues a
deprecation warning and suggests to use avconv instead. Is it worth
converting animation.py from ffmpeg to avconv, too? The command line
arguments should be virtually identicaly (as far as I know - I only
use it very occasionally, though).

Cheers,
Max

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

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

Hi all,

apologies for the delay in getting back to you! The end of last week
was quite busy and I was away from my computer during the weekend.

2012/11/1 Ryan May <rm...@gm...>:
> You might have more luck using a temp-file based writer. By default,
> movies are created by piping in the data to the command; this is much
> faster, but, at least as I've done it now, requires a fixed number of
> bytes per frame. Try passing writer='ffmpeg_file' or
> writer='mencoder_file' to the command to save the animation.

Yes, this works indeed. Thanks for pointing it out! I had feared that
getting the 'bbox_inches' argument to work at all would be much more
involved.

> If I get a chance (or someone else if you want to help), I'll see if
> there's any way to make the pipe-based writers work with
> variable-sized frames.

That would be awesome of course. :)

> Failing that, we could just ignore the tight
> bbox option when using pipes for saving movies.

I like this idea. I have now updated my branch so that the save()
method checks which writer is being used. If it is not a temp
file-based one a warning is issued and the 'bbox_inches' argument is
dropped if it is present (see [1]). Please review and comment. :)

Best regards,
Max

[1] https://github.com/maxalbert/matplotlib/commit/fe44357d04fd708c616e88e386bb06100c12aaca

Re: [matplotlib-devel] colorbar edges in white for PDF output

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

Can you try https://github.com/matplotlib/matplotlib/pull/1446?

Mike

On 11/01/2012 01:59 PM, Andrew Dawson wrote:
> It is possible I have spoken too soon. It certainly fixes the specific 
> issue I was having, however I am now getting serious issues with a 
> plot that uses the basemap toolkit. The contours and coastlines extend 
> way beyond the plot boundaries. I've put links to before and after 
> plots from something I'm working on, I don't have time to do a clean 
> test script tonight though.
>
> I don't know if this is a matplotlib issue or something to do with 
> basemap... some thought is probably required on this one.
>
> http://dl.dropbox.com/u/4496818/bad.pdf
> http://dl.dropbox.com/u/4496818/good.pdf
>
> Andrew
>
>
> On 1 November 2012 16:02, Andrew Dawson <da...@at... 
> <mailto:da...@at...>> wrote:
>
>     Yes this seems to work for me.
>
>
>     On 1 November 2012 15:25, Michael Droettboom <md...@st...
>     <mailto:md...@st...>> wrote:
>
>         I now have a fix attached to that issue. Andrew: can you
>         confirm it works for you?
>
>         Mike
>
>
>         On 11/01/2012 09:06 AM, Michael Droettboom wrote:
>>         I've filed an issue for this here:
>>
>>         https://github.com/matplotlib/matplotlib/issues/1444
>>
>>         Mike
>>
>>         On 10/31/2012 12:20 PM, 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
>>>
>>>
>>>         import matplotlib.pyplot as plt
>>>         import numpy as np
>>>
>>>         # dummy data
>>>         x = y = np.linspace(-np.pi, np.pi, 50)
>>>         X, Y = np.meshgrid(x, y)
>>>         Z = np.sin(X) * np.cos(2.*Y)
>>>
>>>         # draw a filled contour plot and add a colorbar with drawedges turned on
>>>         contours = plt.contourf(x, y, Z)
>>>         cb = plt.colorbar(orientation='horizontal', drawedges=True)
>>>
>>>         # turn off tick marks so the edges can be seen
>>>         for tick in cb.ax.get_xticklines() + cb.ax.get_yticklines():
>>>              tick.set_visible(False)
>>>
>>>         # save as a PDF and a PNG
>>>         plt.savefig('test.pdf')
>>>         plt.savefig('test.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...  <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...
>         <mailto:Mat...@li...>
>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>     -- 
>     Dr Andrew Dawson
>     Atmospheric, Oceanic & Planetary Physics
>     Clarendon Laboratory
>     Parks Road
>     Oxford OX1 3PU, UK
>     Tel: +44 (0)1865 282438 <tel:%2B44%20%280%291865%20282438>
>     Email: da...@at... <mailto:da...@at...>
>     Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson
>
>

Re: [matplotlib-devel] colorbar edges in white for PDF output

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

Thanks.  I think the clipping is getting thrown away by what I just 
did.  It should be an easy fix.

Mike

On 11/01/2012 01:59 PM, Andrew Dawson wrote:
> It is possible I have spoken too soon. It certainly fixes the specific 
> issue I was having, however I am now getting serious issues with a 
> plot that uses the basemap toolkit. The contours and coastlines extend 
> way beyond the plot boundaries. I've put links to before and after 
> plots from something I'm working on, I don't have time to do a clean 
> test script tonight though.
>
> I don't know if this is a matplotlib issue or something to do with 
> basemap... some thought is probably required on this one.
>
> http://dl.dropbox.com/u/4496818/bad.pdf
> http://dl.dropbox.com/u/4496818/good.pdf
>
> Andrew
>
>
> On 1 November 2012 16:02, Andrew Dawson <da...@at... 
> <mailto:da...@at...>> wrote:
>
>     Yes this seems to work for me.
>
>
>     On 1 November 2012 15:25, Michael Droettboom <md...@st...
>     <mailto:md...@st...>> wrote:
>
>         I now have a fix attached to that issue. Andrew: can you
>         confirm it works for you?
>
>         Mike
>
>
>         On 11/01/2012 09:06 AM, Michael Droettboom wrote:
>>         I've filed an issue for this here:
>>
>>         https://github.com/matplotlib/matplotlib/issues/1444
>>
>>         Mike
>>
>>         On 10/31/2012 12:20 PM, 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
>>>
>>>
>>>         import matplotlib.pyplot as plt
>>>         import numpy as np
>>>
>>>         # dummy data
>>>         x = y = np.linspace(-np.pi, np.pi, 50)
>>>         X, Y = np.meshgrid(x, y)
>>>         Z = np.sin(X) * np.cos(2.*Y)
>>>
>>>         # draw a filled contour plot and add a colorbar with drawedges turned on
>>>         contours = plt.contourf(x, y, Z)
>>>         cb = plt.colorbar(orientation='horizontal', drawedges=True)
>>>
>>>         # turn off tick marks so the edges can be seen
>>>         for tick in cb.ax.get_xticklines() + cb.ax.get_yticklines():
>>>              tick.set_visible(False)
>>>
>>>         # save as a PDF and a PNG
>>>         plt.savefig('test.pdf')
>>>         plt.savefig('test.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...  <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...
>         <mailto:Mat...@li...>
>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>     -- 
>     Dr Andrew Dawson
>     Atmospheric, Oceanic & Planetary Physics
>     Clarendon Laboratory
>     Parks Road
>     Oxford OX1 3PU, UK
>     Tel: +44 (0)1865 282438 <tel:%2B44%20%280%291865%20282438>
>     Email: da...@at... <mailto:da...@at...>
>     Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson
>
>

Re: [matplotlib-devel] colorbar edges in white for PDF output

[Andrew D. <aj...@gm...>]

It is possible I have spoken too soon. It certainly fixes the specific
issue I was having, however I am now getting serious issues with a plot
that uses the basemap toolkit. The contours and coastlines extend way
beyond the plot boundaries. I've put links to before and after plots from
something I'm working on, I don't have time to do a clean test script
tonight though.

I don't know if this is a matplotlib issue or something to do with
basemap... some thought is probably required on this one.

http://dl.dropbox.com/u/4496818/bad.pdf
http://dl.dropbox.com/u/4496818/good.pdf

Andrew


On 1 November 2012 16:02, Andrew Dawson <da...@at...> wrote:

> Yes this seems to work for me.
>
>
> On 1 November 2012 15:25, Michael Droettboom <md...@st...> wrote:
>
>>  I now have a fix attached to that issue.  Andrew: can you confirm it
>> works for you?
>>
>> Mike
>>
>>
>> On 11/01/2012 09:06 AM, Michael Droettboom wrote:
>>
>> I've filed an issue for this here:
>>
>> https://github.com/matplotlib/matplotlib/issues/1444
>>
>> Mike
>>
>> On 10/31/2012 12:20 PM, 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
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> # dummy data
>> x = y = np.linspace(-np.pi, np.pi, 50)
>> X, Y = np.meshgrid(x, y)
>> Z = np.sin(X) * np.cos(2.*Y)
>>
>> # draw a filled contour plot and add a colorbar with drawedges turned on
>> contours = plt.contourf(x, y, Z)
>> cb = plt.colorbar(orientation='horizontal', drawedges=True)
>>
>> # turn off tick marks so the edges can be seen
>> for tick in cb.ax.get_xticklines() + cb.ax.get_yticklines():
>>     tick.set_visible(False)
>>
>> # save as a PDF and a PNG
>> plt.savefig('test.pdf')
>> plt.savefig('test.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 lis...@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
>>
>>
>
>
> --
> Dr Andrew Dawson
> Atmospheric, Oceanic & Planetary Physics
> Clarendon Laboratory
> Parks Road
> Oxford OX1 3PU, UK
> Tel: +44 (0)1865 282438
> Email: da...@at...
> Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson
>
>

Re: [matplotlib-devel] colorbar edges in white for PDF output

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

I now have a fix attached to that issue.  Andrew: can you confirm it 
works for you?

Mike

On 11/01/2012 09:06 AM, Michael Droettboom wrote:
> I've filed an issue for this here:
>
> https://github.com/matplotlib/matplotlib/issues/1444
>
> Mike
>
> On 10/31/2012 12:20 PM, 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
>>
>>
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> # dummy data
>> x = y = np.linspace(-np.pi, np.pi, 50)
>> X, Y = np.meshgrid(x, y)
>> Z = np.sin(X) * np.cos(2.*Y)
>>
>> # draw a filled contour plot and add a colorbar with drawedges turned on
>> contours = plt.contourf(x, y, Z)
>> cb = plt.colorbar(orientation='horizontal', drawedges=True)
>>
>> # turn off tick marks so the edges can be seen
>> for tick in cb.ax.get_xticklines() + cb.ax.get_yticklines():
>>      tick.set_visible(False)
>>
>> # save as a PDF and a PNG
>> plt.savefig('test.pdf')
>> plt.savefig('test.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] Animation class: let save() accept **kwargs which are passed on to savefig()?

[Ryan M. <rm...@gm...>]

On Thu, Nov 1, 2012 at 5:38 AM, Maximilian Albert
<max...@gm...> wrote:
> Hi all,
>
> quick update on this: I pushed a small change to make the default
> argument immutable (thanks to Jens for pointing this out). Just a
> couple more questions/comments:
>
> 1) Should there be a test for this? I couldn't find any tests for the
> Animation class, so I haven't added one. But perhaps I just missed
> them.

Sadly there are no tests. Partially because I'm lazy, and partially
because I'm not sure how exactly that would work. I'd gladly take a PR
with some if someone can figure it out, but I realize that's more than
you signed up for.

> 2) I discovered this morning that my change uncovers/introduces a bug
> in the Animation class, so I'd appreciate a bit more input on whether
> it should be merged in the current state. Here is an explanation:
>
> My original use case the suggested change was to be able to set tight
> bounding boxes when saving animation frames. At the time I simply
> saved all frames to separate images and combined them manually using
> avconv, which worked fine. I saw that in the development version of
> matplotlib there is built-in support for this, so that the video file
> is created automatically. Now whenever I change the bounding box, e.g.
> by passing something like savefig_kwargs={'bbox_inches': 'tight'} to
> Animation.save(), then the output video shows complete garbage
> (similar to white noise). I presume this is because the 'frame_size'
> property in the MovieWriter class is not aware of the bounding box
> changes introduced by savefig_kwargs and thus reports a frame size to
> the video converter that is different from the actual size of the
> saved frames.
>
> I don't have much time to look into this at the moment, but I just
> wanted to point it out. Does anyone have a quick idea for a good fix,
> before I get the time to look into the details of how the MovieWriter
> class works?

You might have more luck using a temp-file based writer. By default,
movies are created by piping in the data to the command; this is much
faster, but, at least as I've done it now, requires a fixed number of
bytes per frame. Try passing writer='ffmpeg_file' or
writer='mencoder_file' to the command to save the animation.

If I get a chance (or someone else if you want to help), I'll see if
there's any way to make the pipe-based writers work with
variable-sized frames. Failing that, we could just ignore the tight
bbox option when using pipes for saving movies.

Thanks for the work!

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Re: [matplotlib-devel] colorbar edges in white for PDF output

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

I've filed an issue for this here:

https://github.com/matplotlib/matplotlib/issues/1444

Mike

On 10/31/2012 12:20 PM, 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
>
>
> import matplotlib.pyplot as plt
> import numpy as np
>
> # dummy data
> x = y = np.linspace(-np.pi, np.pi, 50)
> X, Y = np.meshgrid(x, y)
> Z = np.sin(X) * np.cos(2.*Y)
>
> # draw a filled contour plot and add a colorbar with drawedges turned on
> contours = plt.contourf(x, y, Z)
> cb = plt.colorbar(orientation='horizontal', drawedges=True)
>
> # turn off tick marks so the edges can be seen
> for tick in cb.ax.get_xticklines() + cb.ax.get_yticklines():
>      tick.set_visible(False)
>
> # save as a PDF and a PNG
> plt.savefig('test.pdf')
> plt.savefig('test.png')
>

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

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

Hi all,

quick update on this: I pushed a small change to make the default
argument immutable (thanks to Jens for pointing this out). Just a
couple more questions/comments:

1) Should there be a test for this? I couldn't find any tests for the
Animation class, so I haven't added one. But perhaps I just missed
them.

2) I discovered this morning that my change uncovers/introduces a bug
in the Animation class, so I'd appreciate a bit more input on whether
it should be merged in the current state. Here is an explanation:

My original use case the suggested change was to be able to set tight
bounding boxes when saving animation frames. At the time I simply
saved all frames to separate images and combined them manually using
avconv, which worked fine. I saw that in the development version of
matplotlib there is built-in support for this, so that the video file
is created automatically. Now whenever I change the bounding box, e.g.
by passing something like savefig_kwargs={'bbox_inches': 'tight'} to
Animation.save(), then the output video shows complete garbage
(similar to white noise). I presume this is because the 'frame_size'
property in the MovieWriter class is not aware of the bounding box
changes introduced by savefig_kwargs and thus reports a frame size to
the video converter that is different from the actual size of the
saved frames.

I don't have much time to look into this at the moment, but I just
wanted to point it out. Does anyone have a quick idea for a good fix,
before I get the time to look into the details of how the MovieWriter
class works?

Many thanks,
Max


2012/10/31 Maximilian Albert <max...@gm...>:
> 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

Re: [matplotlib-devel] colorbar edges in white for PDF output

[Andrew D. <aj...@gm...>]

I used git bisect to work out where this first happens and it says
https://github.com/matplotlib/matplotlib/commit/4dd3de1b580ac0d7dc53bcca396ba1bf25a8eea9is
the first bad commit. This commit does make changes to the PDF backend
so it seems feasible. Unfortunately I don't know the backend code so this
is currently out of my depth...

Perhaps Michael could weigh in on this? Or others familiar with backend
workings?

Andrew


On 31 October 2012 16:29, Nicolas Rougier <Nic...@in...> wrote:

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

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

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

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

Re: [matplotlib-devel] colorbar edges in white for PDF output

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

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

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

[Jens N. <jen...@gm...>]

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
>

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

[Eric F. <ef...@ha...>]

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
>

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