Hi all, When saving plots (using plt.figsave and matplotlib from SVN) consisting of subplots, the layout is a bit messed up. As an example, have a look at http://mentat.za.net/refer/segmentation.pdf I have tried adjusting the figure size, the font size, the w- and hspace, etc. Is this a known problem, or am I doing something silly? Thanks for your time, Stéfan
Stéfan van der Walt wrote: > Hi all, > > When saving plots (using plt.figsave and matplotlib from SVN) > consisting of subplots, the layout is a bit messed up. As an example, > have a look at > > http://mentat.za.net/refer/segmentation.pdf Wow, that's really ugly! I suspect that for anyone to provide any help on this, you will need to supply a minimal script to show what you are doing. I take it you are starting with something that looks reasonable on the screen, but comes out quite different when you save it? Eric > > I have tried adjusting the figure size, the font size, the w- and > hspace, etc. Is this a known problem, or am I doing something silly? > > Thanks for your time, > Stéfan >
Hi Eric, 2009年9月28日 Eric Firing <ef...@ha...>: >> When saving plots (using plt.figsave and matplotlib from SVN) >> consisting of subplots, the layout is a bit messed up. As an example, >> have a look at >> >> http://mentat.za.net/refer/segmentation.pdf > > Wow, that's really ugly! I suspect that for anyone to provide any help > on this, you will need to supply a minimal script to show what you are > doing. I take it you are starting with something that looks reasonable > on the screen, but comes out quite different when you save it? I narrowed the problem down to this line: matplotlib.rc('figure', dpi=300) Does it do some magic behind the scenes? Attached is the script that produces this: http://mentat.za.net/refer/badplot.pdf I'm running 1.0.svn on OSX Snow Leopard, Python 2.6 and NumPy dev. Regards Stéfan
Stéfan van der Walt wrote: > Hi Eric, > > 2009年9月28日 Eric Firing <ef...@ha...>: >>> When saving plots (using plt.figsave and matplotlib from SVN) >>> consisting of subplots, the layout is a bit messed up. As an example, >>> have a look at >>> >>> http://mentat.za.net/refer/segmentation.pdf >> Wow, that's really ugly! I suspect that for anyone to provide any help >> on this, you will need to supply a minimal script to show what you are >> doing. I take it you are starting with something that looks reasonable >> on the screen, but comes out quite different when you save it? > > I narrowed the problem down to this line: > > matplotlib.rc('figure', dpi=300) > > Does it do some magic behind the scenes? > > Attached is the script that produces this: Stefan, You forgot the attachment. dpi is an inherently confusing parameter because it can relate to font rendering and to the resolution of an image. So there are different kinds of dpi, but the distinction between them is not kept clear in the code--at least it wasn't the last time I looked into this, quite a long time ago. Eric > > http://mentat.za.net/refer/badplot.pdf > > I'm running 1.0.svn on OSX Snow Leopard, Python 2.6 and NumPy dev. > > Regards > Stéfan > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
2009年10月31日 Eric Firing <ef...@ha...>: > You forgot the attachment. I hate it when that happens -- here it is! Cheers Stéfan
2009年11月1日 Stéfan van der Walt <st...@su...>: > 2009年10月31日 Eric Firing <ef...@ha...>: >> You forgot the attachment. > > I hate it when that happens -- here it is! Hey Stéfan, To avoid the overlap on the titles and ticks, you will want to play with the font size of the ticks and title, but most importantly the subplots_adjust parameters hspace and wspace. If using a suptitle, you may also want to adjust top. Eg, # you can also click on the "subplots adjust" toolbar icon to play with the # settings to get something that looks right and then hard code this fig.subplots_adjust(hspace=0.4, wspace=0.4) for ax in ax1, ax2, ax3, ax4: ax.title.set_fontsize(11) for label in ax.get_xticklabels() + ax.get_yticklabels)(): label.set_fontsize(9) You can also use rc parameters to control the defaults: http://matplotlib.sourceforge.net/users/customizing.html JDH
Hi John 2009年11月1日 John Hunter <jd...@gm...>: > To avoid the overlap on the titles and ticks, you will want to play > with the font size of the ticks and title, but most importantly the > subplots_adjust parameters hspace and wspace. > If using a suptitle, you may also want to adjust top. Thanks for the advice, I'll play around with those parameters. I was surprised that this works fine under Linux, so I tried switching to the PDF backend on OSX, and now everything renders perfectly. Could it be that the MacOSX backend does something strange? Regards Stéfan
Stefan, Can you try to install matplotlib again, after removing old ones. The mac os X had a bug that does take care of the dpi. But I guess this bug has been fixed in the svn. http://old.nabble.com/Re%3A-Font-size-and-savefig-p23337463.html -JJ 2009年11月1日 Stéfan van der Walt <st...@su...>: > Hi John > > 2009年11月1日 John Hunter <jd...@gm...>: >> To avoid the overlap on the titles and ticks, you will want to play >> with the font size of the ticks and title, but most importantly the >> subplots_adjust parameters hspace and wspace. >> If using a suptitle, you may also want to adjust top. > > Thanks for the advice, I'll play around with those parameters. > > I was surprised that this works fine under Linux, so I tried switching > to the PDF backend on OSX, and now everything renders perfectly. > Could it be that the MacOSX backend does something strange? > > Regards > Stéfan > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
Hi JJ 2009年11月1日 Jae-Joon Lee <lee...@gm...>: > Can you try to install matplotlib again, after removing old ones. > The mac os X had a bug that does take care of the dpi. But I guess > this bug has been fixed in the svn. Unfortunately, I still see the same behaviour using the latest version from SVN. As noted earlier, I work around the issue now by switching to the pdf backend. Regards Stéfan
I now think this is not the dpi issue.
Can you check the size of your figure in mac os X backend, after the
plot is drawn?
print f.get_size_inches()
8x6 inch is the default.
With dpi setting of 300 and bigger, the figure size (in pixel) will be
likely larger than your monitor size. And it seems that in mac os X
backend, the figure gets shrunken to fit the display, effectively
reducing the figuresize.
So, my recommendation is to use smaller dpi for screen display
(default is something like 80), and increase the dpi when saving the
figure ("savefig" has a dpi parameter).
Regards,
-JJ
2009年11月2日 Stéfan van der Walt <st...@su...>:
> Hi JJ
>
>> this bug has been fixed in the svn.
>
> Unfortunately, I still see the same behaviour using the latest version
> from SVN. As noted earlier, I work around the issue now by switching
> to the pdf backend.
>
> Regards
> Stéfan
>
Hi JJ
2009年11月2日 Jae-Joon Lee <lee...@gm...>:
> I now think this is not the dpi issue.
> Can you check the size of your figure in mac os X backend, after the
> plot is drawn?
>
> print f.get_size_inches()
>
> 8x6 inch is the default.
It says [4, 2.52], so I think you are right!
> So, my recommendation is to use smaller dpi for screen display
> (default is something like 80), and increase the dpi when saving the
> figure ("savefig" has a dpi parameter).
This fixes the problem. Now, why does the MacOSX end do this when
none of the others do?
Thanks for helping me track this down!
Stéfan
2009年11月3日 Stéfan van der Walt <st...@su...>:
> Hi JJ
>
> 2009年11月2日 Jae-Joon Lee <lee...@gm...>:
>> I now think this is not the dpi issue.
>> Can you check the size of your figure in mac os X backend, after the
>> plot is drawn?
>>
>> print f.get_size_inches()
>>
>> 8x6 inch is the default.
>
> It says [4, 2.52], so I think you are right!
>
>> So, my recommendation is to use smaller dpi for screen display
>> (default is something like 80), and increase the dpi when saving the
>> figure ("savefig" has a dpi parameter).
>
> This fixes the problem. Now, why does the MacOSX end do this when
> none of the others do?
>
> Thanks for helping me track this down!
Perhaps you can file a bug report on the tracker so Michiel can look into it?
Thanks,
JDH
2009年11月3日 John Hunter <jd...@gm...>: > Perhaps you can file a bug report on the tracker so Michiel can look into it? Here we go: https://sourceforge.net/tracker/?func=detail&aid=2891502&group_id=80706&atid=560720 Cheers Stéfan
Hi everybody, I was looking at this bug about a memory leak: https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706 While this bug is now essentially fixed, I noticed that the Figure class contains some circular references that prevent it from being cleaned up by the garbage collector, which is effectively a memory leak. At least, for this code: >>> from matplotlib.figure import Figure >>> fig = Figure() >>> del fig the garbage collector reports 76 unreachable objects. This seems to be independent of which backend is being used. Is it worthwhile to look deeper into it? Or should we accept that it is unavoidable that a library of the size of matplotlib will have circular references? --Michiel.
Michiel de Hoon wrote: > Hi everybody, > > I was looking at this bug about a memory leak: > > https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706 > > While this bug is now essentially fixed, I noticed that the Figure class contains some circular references that prevent it from being cleaned up by the garbage collector, which is effectively a memory leak. At least, for this code: > >>>> from matplotlib.figure import Figure >>>> fig = Figure() >>>> del fig > > the garbage collector reports 76 unreachable objects. This seems to be independent of which backend is being used. > > Is it worthwhile to look deeper into it? Or should we accept that it is unavoidable that a library of the size of matplotlib will have circular references? > The purpose of the garbage collector is to handle the case of circular references--and mpl is full of circular references. When there are no circular references, then reference counting suffices. The garbage collector fails to handle circular references when an object has a __del__ method. I don't think we have that problem. I am not actually seeing the result you describe, though. Using python from the interactive prompt--no ipython--when I do gc.collect() and then gc.get_count() I get back to the count from before instantiating the Figure. >>> gc.get_count() (4, 0, 0) >>> gc.get_count() (5, 0, 0) >>> gc.get_count() (5, 0, 0) >>> gc.get_count() (5, 0, 0) >>> fig = Figure() >>> gc.get_count() (128, 0, 0) >>> del(fig) >>> gc.get_count() (128, 0, 0) >>> gc.collect() 76 >>> gc.get_count() (4, 0, 0) >>> gc.get_count() (5, 0, 0) Eric > > --Michiel. >
I guess you're right... I misunderstood the result of gc.collect() as the number of objects that could not be freed. The good news is that after fixing the bug I was looking at, there are no more objects that cannot be freed (gc.garbage is empty). Thanks! --Michiel. --- On Sun, 11/8/09, Eric Firing <ef...@ha...> wrote: > From: Eric Firing <ef...@ha...> > Subject: Re: [matplotlib-devel] Circular references in Figure > To: "Michiel de Hoon" <mjl...@ya...> > Cc: mat...@li... > Date: Sunday, November 8, 2009, 1:43 AM > Michiel de Hoon wrote: > > Hi everybody, > > > > I was looking at this bug about a memory leak: > > > > https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706 > > > > While this bug is now essentially fixed, I noticed > that the Figure class contains some circular references that > prevent it from being cleaned up by the garbage collector, > which is effectively a memory leak. At least, for this > code: > > > >>>> from matplotlib.figure import Figure > >>>> fig = Figure() > >>>> del fig > > > > the garbage collector reports 76 unreachable objects. > This seems to be independent of which backend is being > used. > > > > Is it worthwhile to look deeper into it? Or should we > accept that it is unavoidable that a library of the size of > matplotlib will have circular references? > > > > The purpose of the garbage collector is to handle the case > of circular references--and mpl is full of circular > references. When there are no circular references, > then reference counting suffices. The garbage > collector fails to handle circular references when an object > has a __del__ method. I don't think we have that > problem. > > I am not actually seeing the result you describe, > though. Using python from the interactive prompt--no > ipython--when I do gc.collect() and then gc.get_count() I > get back to the count from before instantiating the Figure. > > >>> gc.get_count() > (4, 0, 0) > >>> gc.get_count() > (5, 0, 0) > >>> gc.get_count() > (5, 0, 0) > >>> gc.get_count() > (5, 0, 0) > >>> fig = Figure() > >>> gc.get_count() > (128, 0, 0) > >>> del(fig) > >>> gc.get_count() > (128, 0, 0) > >>> gc.collect() > 76 > >>> gc.get_count() > (4, 0, 0) > >>> gc.get_count() > (5, 0, 0) > > Eric > > > > > --Michiel. > > >