matplotlib-users Mailing List for matplotlib

2013年8月31日 Dino Bektešević <lj...@gm...>:
> Hello,
>
> After a little mishap from ubuntu 12.04 after which I reinstalled the
> OS, on this fresh install I did:
>
>>sudo apt-get install python-numpy python-scipy python-matplotlib ipython ipython-notebook python-pandas python-sympy python-nose
>
> as per scipy stack installation instructions and
> everything went more or less as it should have no errors reported
> during installation that I saw. Keep in mind the entire install like
> this had ~500MB or so and I wasn't always paying attention.
> I ran python, and did numpy.test(), returned:
>>Ran 3161 tests in 50.667s
>>OK (KNOWNFAIL=3, SKIP=4)
>><nose.result.TextTestResult run=3161 errors=0 failures=0>
>
> did scipy.test(), returned:
>>Ran 3780 tests in 74.809s
>>FAILED (KNOWNFAIL=11, SKIP=13, failures=2)
>><nose.result.TextTestResult run=3780 errors=0 failures=2>
>
> I send a mail to scipy mailing list couple of days ago, but still no answer,
> if someone knows how "bad" those 2 failures are please share and then
> did matplotlib.test() which was disasterous:
>>Ran 1065 tests in 284.956s
>>FAILED (KNOWNFAIL=267, errors=772)
With mpl 1.3.0 (packaged for Raring by Thomas Kluyver):
Ran 1465 tests in 402.499s
FAILED (KNOWNFAIL=1, SKIP=5, errors=1331)
But matplotlib itself is working pretty well. The output is full with
error messages like:
IOError: Baseline image
'/home/goyo/result_images/test_triangulation/tripcolor1-expected.svg'
does not exist.
It maybe that distro packages do not ship with baseline images. Looks
sensible to me since there must be an awful lot of them and most users
do not need them.
Goyo

Hello,
After a little mishap from ubuntu 12.04 after which I reinstalled the
OS, on this fresh install I did:
>sudo apt-get install python-numpy python-scipy python-matplotlib ipython ipython-notebook python-pandas python-sympy python-nose
as per scipy stack installation instructions and
everything went more or less as it should have no errors reported
during installation that I saw. Keep in mind the entire install like
this had ~500MB or so and I wasn't always paying attention.
I ran python, and did numpy.test(), returned:
>Ran 3161 tests in 50.667s
>OK (KNOWNFAIL=3, SKIP=4)
><nose.result.TextTestResult run=3161 errors=0 failures=0>
did scipy.test(), returned:
>Ran 3780 tests in 74.809s
>FAILED (KNOWNFAIL=11, SKIP=13, failures=2)
><nose.result.TextTestResult run=3780 errors=0 failures=2>
I send a mail to scipy mailing list couple of days ago, but still no answer,
if someone knows how "bad" those 2 failures are please share and then
did matplotlib.test() which was disasterous:
>Ran 1065 tests in 284.956s
>FAILED (KNOWNFAIL=267, errors=772)
I've also pasted the entire thing online and it should be availible
for 2 weeks or so:
>http://pastebin.com/rAvnnuCc
>http://pastebin.com/4aPTKJ3V
and for the scipy if anyone is willing:
>http://pastebin.com/FutWAR56
Any help is greatly appreciated,
Dino Bektešević.

I just installed matplotlib-1.3.0.win32-py2.7.exe from
http://matplotlib.org/downloads.html
and I now get the old error:
 ImportError: matplotlib requires dateutil
Is this a policy change? The installation instructions at
 http://matplotlib.org/users/installing.html
still say "Windows users only need the first two (python and numpy)
since the others are built into the matplotlib Windows installers
available for download at the download page. Of course, that points to
 https://github.com/matplotlib/matplotlib/downloads
where 1.3 is not yet available ...
Thanks,
Alan Isaac

I wonder if it's commit 6b827cbf.
Can you do:
 git checkout 6b827cbf
 python setup.py build
 # confirm it fails
 git checkout 6b827cbf^
 python setup.py build
 # Does this work?
Mike
On 08/30/2013 01:06 PM, Nils Wagner wrote:
> Hi Michael,
>
> Thank you for your note.
> If I remember correctly I was able to build matplotlib a week ago.
> I am using opensuse12.3
>
> Nils
>
> rpm -qi python-cxx
> Name : python-cxx
> Version : 6.2.3
> Release : 2.2
> Architecture: noarch
> Install Date: Sa 27 Jul 2013 15:48:45 CEST
> Group : Development/Languages/Python
> Size : 9783
> License : GPL
> Signature : RSA/SHA1, Mo 22 Jul 2013 20:26:22 CEST, Key ID 
> 45a1d0671abd1afb
> Source RPM : python-cxx-6.2.3-2.2.src.rpm
> Build Date : Mo 22 Jul 2013 15:27:08 CEST
> Build Host : swkj07
> Relocations : (not relocatable)
> Packager : pa...@li... <mailto:pa...@li...>
> Vendor : http://packman.links2linux.de
> URL : http://CXX.sourceforge.net/
> Summary : Write Python extensions in C++
> Description :
> PyCXX is a set of classes to help create extensions of Python in the C
> language. The first part encapsulates the Python C API taking care of
> exceptions and ref counting. The second part supports the building of 
> Python
> extension modules in C++.
> Distribution: Extra / openSUSE_12.3
>
>
>
> On Fri, Aug 30, 2013 at 6:46 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> It looks like a version mismatch with PyCXX. Was it recently
> updated or changed? What version of PyCXX do you have? What was
> the last version of matplotlib that worked for you?
>
> You can force matplotlib to use its local copy of PyCXX by
> uninstalling PyCXX, or adding the following lines to the top of
> PyCXX::check in setupext.py:
>
> self.__class__.found_external = False
> return "Couldn't import. Using local copy."
>
> (But really, we should update setupext so users can specify the
> local override in setup.cfg).
>
> Mike
>
>
> On 08/30/2013 12:35 PM, Nils Wagner wrote:
>> Hi all,
>>
>> I cannot build the latest matplotlib from git. The build log is
>> attached.
>>
>> Nils
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li... <mailto:Mat...@li...>
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft
> technologies
> and advance your career. Get an incredible 1,500+ hours of
> step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

It looks like a version mismatch with PyCXX. Was it recently updated or 
changed? What version of PyCXX do you have? What was the last version 
of matplotlib that worked for you?
You can force matplotlib to use its local copy of PyCXX by uninstalling 
PyCXX, or adding the following lines to the top of PyCXX::check in 
setupext.py:
 self.__class__.found_external = False
 return "Couldn't import. Using local copy."
(But really, we should update setupext so users can specify the local 
override in setup.cfg).
Mike
On 08/30/2013 12:35 PM, Nils Wagner wrote:
> Hi all,
>
> I cannot build the latest matplotlib from git. The build log is attached.
>
> Nils
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi all,
I cannot build the latest matplotlib from git. The build log is attached.
Nils

BTW: I've got uploading of test results to S3 working on the main 
matplotlib repository. It would be cool to do that here, too, but I 
believe the encrypted keys are specific to the github repo. We can 
coordinate off-line once the repo is transferred about how to do this.
Mike
On 08/29/2013 01:01 PM, Matt Terry wrote:
>
> (Replying to the list, rather than just George)
> On Aug 29, 2013 8:18 AM, "Matt Terry" <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >
> > I have 15/17 variants working. each pulling binaries/source from 
> some combination of macports/brew/python.org/pip 
> <http://python.org/pip> on python 2.6, 2.7, 3.2, and 3.3.
> >
> > https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
> >
> > I need to add python27 and python33 variants that install XQuartz. 
> Other than that, are there any builds that should be added? For 
> reference,
> >
> > python.org <http://python.org> 27 / pip numpy
> > python.org <http://python.org> 27 / numpy dmg
> > python.org <http://python.org> 33 / pip numpy (no official python3 
> numpy installer)
> > (all built with static versions of libpng/freetype)
> >
> > system python + brew dependencies
> > system python + brew dependencies*
> >
> > brew python27
> > brew python27*
> >
> > brew python33
> > brew python33*
> >
> > macports py26
> > macports py27
> > macports py32
> > macports py33
> > macports py26*
> > macports py27*
> > macports py32*
> > macports py33*
> >
> > * = virtual envs. python & c dependencies installed from package 
> manager; macports, numpy from macports. --with-site-packages
> >
> >
> > I'm having a strange installation issue involving dateutil on python 
> 3.3 (only). It is a bytes vs unicode (fight!) that manifests on 
> installation. I can't reproduce the issue on my machine, but it may 
> have something to do with dateutil v2.1. Anyone seen something like 
> this? installing dateutil via macports cleans up the issue (it 
> installs 2.0, i think).
> >
> > -matt
> >
> >
> >
> >
> > On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gn...@gm... 
> <mailto:gn...@gm...>> wrote:
> >>
> >> It might be useful to see how macports does it -- their builds have 
> always worked for me.
> >>
> >> George Nurser.
> >>
> >>
> >> On 23 August 2013 18:53, Chris Barker - NOAA Federal 
> <chr...@no... <mailto:chr...@no...>> wrote:
> >>>
> >>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >>> > I'm banging away at installing MPL on top of python.org 
> <http://python.org>'s python.
> >>>
> >>> This is why binary installers are good idea!
> >>>
> >>> > the libfreetype/freetype issue.
> >>>
> >>> yeah, that's kind of ugly....and where is doesn't "just work" for 
> me...
> >>>
> >>> > 1) install libpng[1] and freetype[2] from source
> >>>
> >>> libpng and freetype are different, though install from source may be
> >>> the way to go:
> >>>
> >>> libpng is there, but is not properly installed, I'm not sure it's got
> >>> the header for the same version as the lib, and libpng-config is
> >>> either not there or not for the right version or somethign ugly. It
> >>> look, form messages at build time, that someone has hacked some code
> >>> into the MPL build that figures all that out, but for other stuff I'm
> >>> doing, I just punt and build libpng -- that's pretty straighforward,
> >>> at least. But teh solution in the MPL code now seems to work.
> >>>
> >>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> >>> > directions[4]) so MPL finds XQuartz's libpng/freetype
> >>>
> >>> I _think_ that OS-X now ships with X11, which has freetype (though
> >>> installed weirdly once again...) we certainly should NOT expect people
> >>> to install anything big to build MPL, and binaries should not depend
> >>> on anything not shipped by Apple by default.
> >>>
> >>> According to Russell, you do need to install something, so I think 
> that's out.
> >>>
> >>> > 4) create the MPL binary installer and use that
> >>>
> >>> That's what most people should do -- but one of us needs to build it.
> >>>
> >>> > Option 1 seems simple-est, but installing freetype requires more 
> than
> >>> > ./configure && make && sudo make install.
> >>>
> >>> darn. But hopefully we can figure it out.
> >>>
> >>> > Option 4: This would require some input from whoever (Gohlke?, 
> Owen?) makes
> >>> > the binary installers.
> >>>
> >>> I think Russell has been doing it for MPL lately.
> >>>
> >>> My thoughts:
> >>>
> >>> We want to support two user-bases:
> >>>
> >>> 1) folks that don't mind a little command line work, and probably need
> >>> other scientific libs, etc anyway, an want an MPL that runs on their
> >>> machine:
> >>> - these folks should use homebrew or macports to build the
> >>> dependencies (or even hand-compile them). Ideally we have setup.py
> >>> that will find those libs, and test to see that the builds work once
> >>> in a while.
> >>>
> >>> 2) folks that "just want to use it" and/or want a binary they can
> >>> re-distribute via py2app, etc.
> >>> - for these folks, we need to provide binaries. These binaries 
> should:
> >>> 1) Match the python.org <http://python.org> python builds. 
> (probably only the Intel ones now...)
> >>> 2) statically link the non-sytem libs
> >>>
> >>> This has been done for a while, off and on, most recently by 
> Russell, AFAIK.
> >>>
> >>> But this is not a problem unique to MPL. All sorts of python packages
> >>> need this, and only some of the package maintainers do it (well).
> >>> Also, a bunch of packages require the same dependencies (i.e. PIL and
> >>> MPL both need png and freetype)
> >>>
> >>> So, rather than re-inventing the wheel over and over again, It would
> >>> be great to have a central repository where we can develop build
> >>> scripts, etc that share an infrustructure for building these binaries.
> >>>
> >>> I've started one:
> >>>
> >>> https://github.com/MacPython/mac-builds
> >>>
> >>> there is not much there, only a couple things I'm working on at the
> >>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
> >>> is my own simple drawing lib, that no one else uses (yet?)
> >>>
> >>> If anyone wants to join the project let me know -- if I know you from
> >>> your work with this community, I'll gladly add you.
> >>>
> >>> I'm using the gattai build system:
> >>> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
> >>> was sick of re-writing essentially the same build scripts, and I kept
> >>> adding features to mine that would have resulted in re-implementing
> >>> gattai anyway. I've been hacking at gattai, and its author is quite
> >>> open to moving it forward.
> >>>
> >>> That being said, there is no reason that we need to use the same build
> >>> system -- we could easily have custom build scripts for a project, and
> >>> still have it share the dependencies.
> >>>
> >>> I was planning on getting it all further along before announcing the
> >>> project and looking for help, but since is came up...
> >>>
> >>> -Chris
> >>>
> >>> --
> >>>
> >>> Christopher Barker, Ph.D.
> >>> Oceanographer
> >>>
> >>> Emergency Response Division
> >>> NOAA/NOS/OR&R (206) 526-6959 voice
> >>> 7600 Sand Point Way NE (206) 526-6329 fax
> >>> Seattle, WA 98115 (206) 526-6317 main reception
> >>>
> >>> Chr...@no... <mailto:Chr...@no...>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> Introducing Performance Central, a new site from SourceForge and
> >>> AppDynamics. Performance Central is your source for news, insights,
> >>> analysis and resources for efficient Application Performance 
> Management.
> >>> Visit us today!
> >>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Matplotlib-users mailing list
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> >> Discover the easy way to master current and previous Microsoft 
> technologies
> >> and advance your career. Get an incredible 1,500+ hours of step-by-step
> >> tutorial videos with LearnDevNow. Subscribe today and save!
> >> 
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Very impressive! This is really great.
That does sure look like a dateutil bug. Maybe we try reporting it over 
there?
As for transferring the repository... I've added you as a developer in 
the matplotlib organization, so you can work over there. And it looks 
like you are the only one who can do the transfer, see here: 
https://help.github.com/articles/how-to-transfer-a-repository
I'll ping Travis again about how multi-OS testing might work, because it 
would be *absolutely killer* to get this going on matplotlib PRs.
Mike
On 08/29/2013 01:01 PM, Matt Terry wrote:
>
> (Replying to the list, rather than just George)
> On Aug 29, 2013 8:18 AM, "Matt Terry" <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >
> > I have 15/17 variants working. each pulling binaries/source from 
> some combination of macports/brew/python.org/pip 
> <http://python.org/pip> on python 2.6, 2.7, 3.2, and 3.3.
> >
> > https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
> >
> > I need to add python27 and python33 variants that install XQuartz. 
> Other than that, are there any builds that should be added? For 
> reference,
> >
> > python.org <http://python.org> 27 / pip numpy
> > python.org <http://python.org> 27 / numpy dmg
> > python.org <http://python.org> 33 / pip numpy (no official python3 
> numpy installer)
> > (all built with static versions of libpng/freetype)
> >
> > system python + brew dependencies
> > system python + brew dependencies*
> >
> > brew python27
> > brew python27*
> >
> > brew python33
> > brew python33*
> >
> > macports py26
> > macports py27
> > macports py32
> > macports py33
> > macports py26*
> > macports py27*
> > macports py32*
> > macports py33*
> >
> > * = virtual envs. python & c dependencies installed from package 
> manager; macports, numpy from macports. --with-site-packages
> >
> >
> > I'm having a strange installation issue involving dateutil on python 
> 3.3 (only). It is a bytes vs unicode (fight!) that manifests on 
> installation. I can't reproduce the issue on my machine, but it may 
> have something to do with dateutil v2.1. Anyone seen something like 
> this? installing dateutil via macports cleans up the issue (it 
> installs 2.0, i think).
> >
> > -matt
> >
> >
> >
> >
> > On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gn...@gm... 
> <mailto:gn...@gm...>> wrote:
> >>
> >> It might be useful to see how macports does it -- their builds have 
> always worked for me.
> >>
> >> George Nurser.
> >>
> >>
> >> On 23 August 2013 18:53, Chris Barker - NOAA Federal 
> <chr...@no... <mailto:chr...@no...>> wrote:
> >>>
> >>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >>> > I'm banging away at installing MPL on top of python.org 
> <http://python.org>'s python.
> >>>
> >>> This is why binary installers are good idea!
> >>>
> >>> > the libfreetype/freetype issue.
> >>>
> >>> yeah, that's kind of ugly....and where is doesn't "just work" for 
> me...
> >>>
> >>> > 1) install libpng[1] and freetype[2] from source
> >>>
> >>> libpng and freetype are different, though install from source may be
> >>> the way to go:
> >>>
> >>> libpng is there, but is not properly installed, I'm not sure it's got
> >>> the header for the same version as the lib, and libpng-config is
> >>> either not there or not for the right version or somethign ugly. It
> >>> look, form messages at build time, that someone has hacked some code
> >>> into the MPL build that figures all that out, but for other stuff I'm
> >>> doing, I just punt and build libpng -- that's pretty straighforward,
> >>> at least. But teh solution in the MPL code now seems to work.
> >>>
> >>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> >>> > directions[4]) so MPL finds XQuartz's libpng/freetype
> >>>
> >>> I _think_ that OS-X now ships with X11, which has freetype (though
> >>> installed weirdly once again...) we certainly should NOT expect people
> >>> to install anything big to build MPL, and binaries should not depend
> >>> on anything not shipped by Apple by default.
> >>>
> >>> According to Russell, you do need to install something, so I think 
> that's out.
> >>>
> >>> > 4) create the MPL binary installer and use that
> >>>
> >>> That's what most people should do -- but one of us needs to build it.
> >>>
> >>> > Option 1 seems simple-est, but installing freetype requires more 
> than
> >>> > ./configure && make && sudo make install.
> >>>
> >>> darn. But hopefully we can figure it out.
> >>>
> >>> > Option 4: This would require some input from whoever (Gohlke?, 
> Owen?) makes
> >>> > the binary installers.
> >>>
> >>> I think Russell has been doing it for MPL lately.
> >>>
> >>> My thoughts:
> >>>
> >>> We want to support two user-bases:
> >>>
> >>> 1) folks that don't mind a little command line work, and probably need
> >>> other scientific libs, etc anyway, an want an MPL that runs on their
> >>> machine:
> >>> - these folks should use homebrew or macports to build the
> >>> dependencies (or even hand-compile them). Ideally we have setup.py
> >>> that will find those libs, and test to see that the builds work once
> >>> in a while.
> >>>
> >>> 2) folks that "just want to use it" and/or want a binary they can
> >>> re-distribute via py2app, etc.
> >>> - for these folks, we need to provide binaries. These binaries 
> should:
> >>> 1) Match the python.org <http://python.org> python builds. 
> (probably only the Intel ones now...)
> >>> 2) statically link the non-sytem libs
> >>>
> >>> This has been done for a while, off and on, most recently by 
> Russell, AFAIK.
> >>>
> >>> But this is not a problem unique to MPL. All sorts of python packages
> >>> need this, and only some of the package maintainers do it (well).
> >>> Also, a bunch of packages require the same dependencies (i.e. PIL and
> >>> MPL both need png and freetype)
> >>>
> >>> So, rather than re-inventing the wheel over and over again, It would
> >>> be great to have a central repository where we can develop build
> >>> scripts, etc that share an infrustructure for building these binaries.
> >>>
> >>> I've started one:
> >>>
> >>> https://github.com/MacPython/mac-builds
> >>>
> >>> there is not much there, only a couple things I'm working on at the
> >>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
> >>> is my own simple drawing lib, that no one else uses (yet?)
> >>>
> >>> If anyone wants to join the project let me know -- if I know you from
> >>> your work with this community, I'll gladly add you.
> >>>
> >>> I'm using the gattai build system:
> >>> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
> >>> was sick of re-writing essentially the same build scripts, and I kept
> >>> adding features to mine that would have resulted in re-implementing
> >>> gattai anyway. I've been hacking at gattai, and its author is quite
> >>> open to moving it forward.
> >>>
> >>> That being said, there is no reason that we need to use the same build
> >>> system -- we could easily have custom build scripts for a project, and
> >>> still have it share the dependencies.
> >>>
> >>> I was planning on getting it all further along before announcing the
> >>> project and looking for help, but since is came up...
> >>>
> >>> -Chris
> >>>
> >>> --
> >>>
> >>> Christopher Barker, Ph.D.
> >>> Oceanographer
> >>>
> >>> Emergency Response Division
> >>> NOAA/NOS/OR&R (206) 526-6959 voice
> >>> 7600 Sand Point Way NE (206) 526-6329 fax
> >>> Seattle, WA 98115 (206) 526-6317 main reception
> >>>
> >>> Chr...@no... <mailto:Chr...@no...>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> Introducing Performance Central, a new site from SourceForge and
> >>> AppDynamics. Performance Central is your source for news, insights,
> >>> analysis and resources for efficient Application Performance 
> Management.
> >>> Visit us today!
> >>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Matplotlib-users mailing list
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> >> Discover the easy way to master current and previous Microsoft 
> technologies
> >> and advance your career. Get an incredible 1,500+ hours of step-by-step
> >> tutorial videos with LearnDevNow. Subscribe today and save!
> >> 
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Eric,
Le 29/08/2013 19:51, Eric Frederich a écrit :
> I took the example that ships with 1.3.0 and have modified it to use a
> grid layout and show 9 graphs in a 3x3 grid.
> When I do this it, other widgets become rather unresponsive.
> Is there a way to fix this?
> Somehow offload whatever is hogging CPU onto another thread or something?
I just ran your code on my computer and I don't get the unresponsive
widgets problem. The program takes 6% of one CPU.
Yet the slider is not totally fluid. It gets better if I slowdown the
plot update timer.
Do you run your code on a powerful computer ?
best,
Pierre

I took the example that ships with 1.3.0 and have modified it to use a grid
layout and show 9 graphs in a 3x3 grid.
When I do this it, other widgets become rather unresponsive.
Is there a way to fix this?
Somehow offload whatever is hogging CPU onto another thread or something?
Below is the code....
Thanks,
~Eric
#!/usr/bin/env python
# embedding_in_qt4.py --- Simple Qt4 application embedding matplotlib
canvases
#
# Copyright (C) 2005 Florent Rougon
# 2006 Darren Dale
#
# This file is an example program for matplotlib. It may be used and
# modified with no restriction; raw copies as well as modified versions
# may be distributed without limitation.
from __future__ import unicode_literals
import sys, os, random
from PyQt4 import QtGui, QtCore
from numpy import arange, sin, pi
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as
FigureCanvas
from matplotlib.figure import Figure
progname = os.path.basename(sys.argv[0])
progversion = "0.1"
class MyMplCanvas(FigureCanvas):
 """Ultimately, this is a QWidget (as well as a FigureCanvasAgg,
etc.)."""
 def __init__(self, parent=None, width=5, height=4, dpi=100):
 fig = Figure(figsize=(width, height), dpi=dpi)
 self.axes = fig.add_subplot(111)
 # We want the axes cleared every time plot() is called
 self.axes.hold(False)
 self.compute_initial_figure()
 #
 FigureCanvas.__init__(self, fig)
 self.setParent(parent)
 FigureCanvas.setSizePolicy(self,
 QtGui.QSizePolicy.Expanding,
 QtGui.QSizePolicy.Expanding)
 FigureCanvas.updateGeometry(self)
 def compute_initial_figure(self):
 pass
class MyDynamicMplCanvas(MyMplCanvas):
 """A canvas that updates itself every second with a new plot."""
 def __init__(self, *args, **kwargs):
 MyMplCanvas.__init__(self, *args, **kwargs)
 timer = QtCore.QTimer(self)
 QtCore.QObject.connect(timer, QtCore.SIGNAL("timeout()"),
self.update_figure)
 timer.start(750)
 def compute_initial_figure(self):
 self.axes.plot([0, 1, 2, 3], [1, 2, 0, 4], 'r')
 def update_figure(self):
 # Build a list of 4 random integers between 0 and 10 (both
inclusive)
 l = [ random.randint(0, 10) for i in range(4) ]
 self.axes.plot([0, 1, 2, 3], l, 'r')
 self.draw()
class ApplicationWindow(QtGui.QMainWindow):
 def __init__(self):
 QtGui.QMainWindow.__init__(self)
 self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
 self.setWindowTitle("Unresponsive Application")
 self.file_menu = QtGui.QMenu('&File', self)
 self.file_menu.addAction('&Quit', self.fileQuit, QtCore.Qt.CTRL +
QtCore.Qt.Key_Q)
 self.menuBar().addMenu(self.file_menu)
 self.help_menu = QtGui.QMenu('&Help', self)
 self.menuBar().addSeparator()
 self.menuBar().addMenu(self.help_menu)
 self.help_menu.addAction('&About', self.about)
 self.main_widget = QtGui.QWidget(self)
 main_layout = QtGui.QVBoxLayout()
 chart_layout = QtGui.QGridLayout()
 for row in range(3):
 for col in range(3):
 dc = MyDynamicMplCanvas(self.main_widget, width=5,
height=4, dpi=100)
 chart_layout.addWidget(dc, row, col)
 main_layout.addWidget(QtGui.QPushButton("Unresponsive"))
 main_layout.addWidget(QtGui.QPushButton("Widgets"))
 horizontalSlider = QtGui.QSlider()
 horizontalSlider.setOrientation(QtCore.Qt.Horizontal)
 main_layout.addWidget(horizontalSlider)
 main_layout.addLayout(chart_layout)
 self.main_widget.setLayout(main_layout)
 self.main_widget.setFocus()
 self.setCentralWidget(self.main_widget)
 self.statusBar().showMessage("All hail matplotlib!", 2000)
 def fileQuit(self):
 self.close()
 def closeEvent(self, ce):
 self.fileQuit()
 def about(self):
 QtGui.QMessageBox.about(self, "About",
"""embedding_in_qt4.py example
Copyright 2005 Florent Rougon, 2006 Darren Dale
This program is a simple example of a Qt4 application embedding matplotlib
canvases.
It may be used and modified with no restriction; raw copies as well as
modified versions may be distributed without limitation."""
)
if __name__ == '__main__':
 app = QtGui.QApplication(sys.argv)
 aw = ApplicationWindow()
 aw.show()
 sys.exit(app.exec_())

(Replying to the list, rather than just George)
On Aug 29, 2013 8:18 AM, "Matt Terry" <mat...@gm...> wrote:
>
> I have 15/17 variants working. each pulling binaries/source from some
combination of macports/brew/python.org/pip on python 2.6, 2.7, 3.2, and
3.3.
>
> https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
>
> I need to add python27 and python33 variants that install XQuartz. Other
than that, are there any builds that should be added? For reference,
>
> python.org 27 / pip numpy
> python.org 27 / numpy dmg
> python.org 33 / pip numpy (no official python3 numpy installer)
> (all built with static versions of libpng/freetype)
>
> system python + brew dependencies
> system python + brew dependencies*
>
> brew python27
> brew python27*
>
> brew python33
> brew python33*
>
> macports py26
> macports py27
> macports py32
> macports py33
> macports py26*
> macports py27*
> macports py32*
> macports py33*
>
> * = virtual envs. python & c dependencies installed from package manager;
macports, numpy from macports. --with-site-packages
>
>
> I'm having a strange installation issue involving dateutil on python 3.3
(only). It is a bytes vs unicode (fight!) that manifests on installation.
I can't reproduce the issue on my machine, but it may have something to do
with dateutil v2.1. Anyone seen something like this? installing dateutil
via macports cleans up the issue (it installs 2.0, i think).
>
> -matt
>
>
>
>
> On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gn...@gm...> wrote:
>>
>> It might be useful to see how macports does it -- their builds have
always worked for me.
>>
>> George Nurser.
>>
>>
>> On 23 August 2013 18:53, Chris Barker - NOAA Federal <
chr...@no...> wrote:
>>>
>>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm...>
wrote:
>>> > I'm banging away at installing MPL on top of python.org's python.
>>>
>>> This is why binary installers are good idea!
>>>
>>> > the libfreetype/freetype issue.
>>>
>>> yeah, that's kind of ugly....and where is doesn't "just work" for me...
>>>
>>> > 1) install libpng[1] and freetype[2] from source
>>>
>>> libpng and freetype are different, though install from source may be
>>> the way to go:
>>>
>>> libpng is there, but is not properly installed, I'm not sure it's got
>>> the header for the same version as the lib, and libpng-config is
>>> either not there or not for the right version or somethign ugly. It
>>> look, form messages at build time, that someone has hacked some code
>>> into the MPL build that figures all that out, but for other stuff I'm
>>> doing, I just punt and build libpng -- that's pretty straighforward,
>>> at least. But teh solution in the MPL code now seems to work.
>>>
>>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
>>> > directions[4]) so MPL finds XQuartz's libpng/freetype
>>>
>>> I _think_ that OS-X now ships with X11, which has freetype (though
>>> installed weirdly once again...) we certainly should NOT expect people
>>> to install anything big to build MPL, and binaries should not depend
>>> on anything not shipped by Apple by default.
>>>
>>> According to Russell, you do need to install something, so I think
that's out.
>>>
>>> > 4) create the MPL binary installer and use that
>>>
>>> That's what most people should do -- but one of us needs to build it.
>>>
>>> > Option 1 seems simple-est, but installing freetype requires more than
>>> > ./configure && make && sudo make install.
>>>
>>> darn. But hopefully we can figure it out.
>>>
>>> > Option 4: This would require some input from whoever (Gohlke?, Owen?)
makes
>>> > the binary installers.
>>>
>>> I think Russell has been doing it for MPL lately.
>>>
>>> My thoughts:
>>>
>>> We want to support two user-bases:
>>>
>>> 1) folks that don't mind a little command line work, and probably need
>>> other scientific libs, etc anyway, an want an MPL that runs on their
>>> machine:
>>> - these folks should use homebrew or macports to build the
>>> dependencies (or even hand-compile them). Ideally we have setup.py
>>> that will find those libs, and test to see that the builds work once
>>> in a while.
>>>
>>> 2) folks that "just want to use it" and/or want a binary they can
>>> re-distribute via py2app, etc.
>>> - for these folks, we need to provide binaries. These binaries should:
>>> 1) Match the python.org python builds. (probably only the Intel ones
now...)
>>> 2) statically link the non-sytem libs
>>>
>>> This has been done for a while, off and on, most recently by Russell,
AFAIK.
>>>
>>> But this is not a problem unique to MPL. All sorts of python packages
>>> need this, and only some of the package maintainers do it (well).
>>> Also, a bunch of packages require the same dependencies (i.e. PIL and
>>> MPL both need png and freetype)
>>>
>>> So, rather than re-inventing the wheel over and over again, It would
>>> be great to have a central repository where we can develop build
>>> scripts, etc that share an infrustructure for building these binaries.
>>>
>>> I've started one:
>>>
>>> https://github.com/MacPython/mac-builds
>>>
>>> there is not much there, only a couple things I'm working on at the
>>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
>>> is my own simple drawing lib, that no one else uses (yet?)
>>>
>>> If anyone wants to join the project let me know -- if I know you from
>>> your work with this community, I'll gladly add you.
>>>
>>> I'm using the gattai build system:
>>> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
>>> was sick of re-writing essentially the same build scripts, and I kept
>>> adding features to mine that would have resulted in re-implementing
>>> gattai anyway. I've been hacking at gattai, and its author is quite
>>> open to moving it forward.
>>>
>>> That being said, there is no reason that we need to use the same build
>>> system -- we could easily have custom build scripts for a project, and
>>> still have it share the dependencies.
>>>
>>> I was planning on getting it all further along before announcing the
>>> project and looking for help, but since is came up...
>>>
>>> -Chris
>>>
>>> --
>>>
>>> Christopher Barker, Ph.D.
>>> Oceanographer
>>>
>>> Emergency Response Division
>>> NOAA/NOS/OR&R (206) 526-6959 voice
>>> 7600 Sand Point Way NE (206) 526-6329 fax
>>> Seattle, WA 98115 (206) 526-6317 main reception
>>>
>>> Chr...@no...
>>>
>>>
------------------------------------------------------------------------------
>>> Introducing Performance Central, a new site from SourceForge and
>>> AppDynamics. Performance Central is your source for news, insights,
>>> analysis and resources for efficient Application Performance Management.
>>> Visit us today!
>>>
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>>
------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft
technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>>
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

It might be useful to see how macports does it -- their builds have always
worked for me.
George Nurser.
On 23 August 2013 18:53, Chris Barker - NOAA Federal
<chr...@no...>wrote:
> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm...> wrote:
> > I'm banging away at installing MPL on top of python.org's python.
>
> This is why binary installers are good idea!
>
> > the libfreetype/freetype issue.
>
> yeah, that's kind of ugly....and where is doesn't "just work" for me...
>
> > 1) install libpng[1] and freetype[2] from source
>
> libpng and freetype are different, though install from source may be
> the way to go:
>
> libpng is there, but is not properly installed, I'm not sure it's got
> the header for the same version as the lib, and libpng-config is
> either not there or not for the right version or somethign ugly. It
> look, form messages at build time, that someone has hacked some code
> into the MPL build that figures all that out, but for other stuff I'm
> doing, I just punt and build libpng -- that's pretty straighforward,
> at least. But teh solution in the MPL code now seems to work.
>
> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> > directions[4]) so MPL finds XQuartz's libpng/freetype
>
> I _think_ that OS-X now ships with X11, which has freetype (though
> installed weirdly once again...) we certainly should NOT expect people
> to install anything big to build MPL, and binaries should not depend
> on anything not shipped by Apple by default.
>
> According to Russell, you do need to install something, so I think that's
> out.
>
> > 4) create the MPL binary installer and use that
>
> That's what most people should do -- but one of us needs to build it.
>
> > Option 1 seems simple-est, but installing freetype requires more than
> > ./configure && make && sudo make install.
>
> darn. But hopefully we can figure it out.
>
> > Option 4: This would require some input from whoever (Gohlke?, Owen?)
> makes
> > the binary installers.
>
> I think Russell has been doing it for MPL lately.
>
> My thoughts:
>
> We want to support two user-bases:
>
> 1) folks that don't mind a little command line work, and probably need
> other scientific libs, etc anyway, an want an MPL that runs on their
> machine:
> - these folks should use homebrew or macports to build the
> dependencies (or even hand-compile them). Ideally we have setup.py
> that will find those libs, and test to see that the builds work once
> in a while.
>
> 2) folks that "just want to use it" and/or want a binary they can
> re-distribute via py2app, etc.
> - for these folks, we need to provide binaries. These binaries should:
> 1) Match the python.org python builds. (probably only the Intel ones
> now...)
> 2) statically link the non-sytem libs
>
> This has been done for a while, off and on, most recently by Russell,
> AFAIK.
>
> But this is not a problem unique to MPL. All sorts of python packages
> need this, and only some of the package maintainers do it (well).
> Also, a bunch of packages require the same dependencies (i.e. PIL and
> MPL both need png and freetype)
>
> So, rather than re-inventing the wheel over and over again, It would
> be great to have a central repository where we can develop build
> scripts, etc that share an infrustructure for building these binaries.
>
> I've started one:
>
> https://github.com/MacPython/mac-builds
>
> there is not much there, only a couple things I'm working on at the
> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
> is my own simple drawing lib, that no one else uses (yet?)
>
> If anyone wants to join the project let me know -- if I know you from
> your work with this community, I'll gladly add you.
>
> I'm using the gattai build system:
> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
> was sick of re-writing essentially the same build scripts, and I kept
> adding features to mine that would have resulted in re-implementing
> gattai anyway. I've been hacking at gattai, and its author is quite
> open to moving it forward.
>
> That being said, there is no reason that we need to use the same build
> system -- we could easily have custom build scripts for a project, and
> still have it share the dependencies.
>
> I was planning on getting it all further along before announcing the
> project and looking for help, but since is came up...
>
> -Chris
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Wed, Aug 28, 2013 at 06:39:26PM +0200, vwf wrote:
> Hello,
> 
> I would like to create a surface with a color provided by an independent
> variable. 
Got something working:
import matplotlib.pyplot as plt
import numpy as np
from mpl_toolkits.mplot3d import Axes3D
from matplotlib import cm
from matplotlib.ticker import LinearLocator, FormatStrFormatter
no=100
#========================================
# color trick to draw with varying alpha
# http://matplotlib.1069221.n5.nabble.com/scatter-plot-individual-alpha-values-td21106.html
#========================================
from matplotlib.colors import LinearSegmentedColormap
class LinearColormap(LinearSegmentedColormap):
 def __init__(self, name, segmented_data, index=None, **kwargs):
 if index is None:
 # If index not given, RGB colors are evenly-spaced in
 # colormap.
 index = np.linspace(0, 1, len(segmented_data['red']))
 for key, value in segmented_data.iteritems():
 # Combine color index with color values.
 segmented_data[key] = zip(index, value)
 segmented_data = dict((key, [(x, y, y) for x, y in value])
 for key, value in
segmented_data.iteritems())
 LinearSegmentedColormap.__init__(self, name, segmented_data, **kwargs)
color_spec = {'blue': [0.0, 0.0],
 'green': [1.0, 0.0],
 'red': [0.0, 1.0],
 'alpha': [0.1, 1.0]}
alpha_color = LinearColormap('alpha_color', color_spec)
#==========================================
fig = plt.figure()
ax = fig.gca(projection = '3d')
x = np.linspace(-5,5,no)
y = np.linspace(-5,5,no)
x,y = np.meshgrid(x,y)
R = np.sqrt(x**2 + y**2)
z = np.sin(R)
D = np.sqrt((x-5)**2 + (y-5)**2)
c=np.zeros(shape=(no,no),dtype=object)
for i in range(no):
 for j in range(no):
 c[i,j]=alpha_color(D[i,i]/15)
surf = ax.plot_surface(x, y, z, facecolors=c, rstride = 1, cstride = 1, linewidth = 0)
ax.set_zlim3d(-2, 2)
plt.show()

Hello,
I would like to create a surface with a color provided by an independent
variable. The shape is defined by a matrix with the z-values. The
color is a matrix of identical shape with floats. Can this be done?
My experiment code is incomplete: I could not write anything useful. Can
onyone help me making it work?
Thank you
import matplotlib.pyplot as plt
import numpy as np
from mpl_toolkits.mplot3d import Axes3D
from matplotlib import cm
from matplotlib.ticker import LinearLocator, FormatStrFormatter
no=100
cdict = {'red': ((0.0, 0.0, 0.0),
 (15.0, 1.0, 1.0)),
 'green': ((0.0, 0.0, 0.0),
 (15.0, 0.0, 0.0)),
 'blue': ((0.0, 1.0, 1.0),
 (15.0, 0.0, 0.0))}
fig = plt.figure()
ax = fig.gca(projection = '3d')
x = np.linspace(-5,5,no)
y = np.linspace(-5,5,no)
x,y = np.meshgrid(x,y)
R = np.sqrt(x**2 + y**2)
z = np.sin(R)
D = np.sqrt((x-5)**2 + (y-5)**2)
#and now I need to map distance D 
#making (-5,-5) blue and (5,5) red
c= 
surf = ax.plot_surface(x, y, z, facecolors=c, rstride = 1, cstride = 1, cmap = jet, linewidth = 0)
ax.set_zlim3d(-2, 2)
plt.show()

Hi,
I'm currently working on my master thesis, which heavily involves 
creating plots and images. I recently found out about the pdf_tex 
feature of Inkscape, which basically creates a seperate LaTeX file 
besides the normal *.pdf output, to store the text. The advantage of 
this method is that the text displayed in the included pdf matches 
exactly the size of your font in the rest of your document, even when 
resizing the image. This is just a brilliant feature as it allows me to 
fit the width of the images to my column or textwidth while having the 
same font size for all images, it just looks amazing. While this work 
pretty well for the images i draw myself, i tried to find a similar 
feature for my matplotlib plots. The closest format to pdf_tex i found 
was pgf. But i have a major issue with this pgf format. When i resize 
the picture in LaTeX it also resizes the font size. Is there a way to 
get arround this issue? Guess i could resize the plot in matplotlib to 
fit approximately the page width and just include the pgf without 
resizing it, but i want a consistent look of all my images/plots in my 
thesis. Right now, I don't see any advantage over using just a plain pdf 
output using matplotlib, besides using the same font as in the rest of 
my document (but using pgf to include my plots / images also takes a lot 
more time to compile).
I'm not bound to pgf images, so if there is a vector graphic solution 
which let's me keep the same font size no matter how i resize my 
picture, I would go with it. I guess i could save the image as a svg and 
save it with inkscape to pdf_tex, but as i allready mentioned i have a 
lot of images / plots.
I would really appreciate any suggestions.
Regards
Benjamin Isbarn
PS: Excuse my bad english :)
PPS: It doesn't seem to be easy to resize a pgf picture to the textwidth 
or columnwidth either (because of the \input statement, right now i'm 
using \scalebox{}{}). So an alternative to pgf wouldn't be bad.

Hi Chris,
"
I've used some hacky tricks to get around this, which mostly involve 
downsampling the image on the fly based on screen resolution. One such 
effort is at https://github.com/ChrisBeaumont/mpl-modest-image
(https://github.com/ChrisBeaumont/mpl-modest-image). 
"
I tried your code for plotting 4kx4k image and it is another significant 
improvement. Originally it took 300 MB then it was reduced to 190 MB with 
uint8 type and using your ModestImage class it takes 70-100 MB depending on
size of window.
That is much better!
Best
Stepan

Hi Martin,
"Hi,
I knw you asked for memory profiling but I could not resist and did CPU 
profiling on your testcase. I have attached some screenshots and in words:
"
thanks for these tips about profiling. 
Stepan

On 08/27/2013 09:49 AM, Chris Beaumont wrote:
> I've been burned by this before as well. MPL stores some intermediate 
> data products (for example, scaled RGB copies) at full resolution, 
> even though the final rendered image is downsampled depending on 
> screen resolution.
>
> I've used some hacky tricks to get around this, which mostly involve 
> downsampling the image on the fly based on screen resolution. One such 
> effort is at https://github.com/ChrisBeaumont/mpl-modest-image.
It looks like this wouldn't be too hard to include in matplotlib. I 
don't think we'd want to change the current behavior, because sometimes 
its tradeoff curve makes sense, but in other cases, the "modest image" 
approach also makes sense. It's just a matter of coming up with an API 
to switch between the two behaviors. Pull request?
Cheers,
Mike
>
> If you are loading your arrays from disk, you can also use 
> memory-mapped arrays -- this prevents you from loading all the data 
> into RAM, and further cuts down on the footprint.
>
> cheers,
> chris
>
>
> On Tue, Aug 27, 2013 at 6:49 AM, S(te(pán Turek 
> <ste...@se... <mailto:ste...@se...>> wrote:
>
>
> You could look at whether or not you actually need 64-bit
> precision. Often times, 8-bit precision per color channel is
> justifiable, even in grayscale. My advice is to play with the
> dtype of your array or, as you mentioned, resample.
>
>
> thanks, this helped me significantly, uint8 precision is enough.
>
> Also, is it needed to keep all images? It sounds to me like
> your application will become very resource hungry if you're
> going to be displaying several of these 2D images over each
> other (and if you don't use transparency, you won't get any
> benefit at all from plotting them together).
>
>
> Yes, I need them all .
>
> To avoid it I am thinking about merging them into one image and
> then plot it.
>
>
> Stepan
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance
> Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I've been burned by this before as well. MPL stores some intermediate data
products (for example, scaled RGB copies) at full resolution, even though
the final rendered image is downsampled depending on screen resolution.
I've used some hacky tricks to get around this, which mostly involve
downsampling the image on the fly based on screen resolution. One such
effort is at https://github.com/ChrisBeaumont/mpl-modest-image.
If you are loading your arrays from disk, you can also use memory-mapped
arrays -- this prevents you from loading all the data into RAM, and further
cuts down on the footprint.
cheers,
chris
On Tue, Aug 27, 2013 at 6:49 AM, Štěpán Turek <ste...@se...>wrote:
>
> You could look at whether or not you actually need 64-bit precision. Often
> times, 8-bit precision per color channel is justifiable, even in grayscale.
> My advice is to play with the dtype of your array or, as you mentioned,
> resample.
>
>
> thanks, this helped me significantly, uint8 precision is enough.
>
>
>
> Also, is it needed to keep all images? It sounds to me like your
> application will become very resource hungry if you're going to be
> displaying several of these 2D images over each other (and if you don't use
> transparency, you won't get any benefit at all from plotting them together).
>
>
> Yes, I need them all .
>
> To avoid it I am thinking about merging them into one image and then plot
> it.
>
>
> Stepan
>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

"
""
You could look at whether or not you actually need 64-bit precision. Often 
times, 8-bit precision per color channel is justifiable, even in grayscale. 
My advice is to play with the dtype of your array or, as you mentioned, 
resample. 
"
thanks, this helped me significantly, uint8 precision is enough.
 
"
Also, is it needed to keep all images? It sounds to me like your application
will become very resource hungry if you're going to be displaying several of
these 2D images over each other (and if you don't use transparency, you won'
t get any benefit at all from plotting them together).
"
Yes, I need them all .
To avoid it I am thinking about merging them into one image and then plot 
it. 
Stepan
"
 
"

Those numbers actually make a lot of sense.
For a 4k by 4k 2D array of 64-bit floats, you're using 128MiB of memory,
just to store them. Displaying such an array with mpl would take a copy of
that and add some objects for housekeeping (on my machine about 150MB to
display one such array together with the housekeeping objects).
You could look at whether or not you actually need 64-bit precision. Often
times, 8-bit precision per color channel is justifiable, even in grayscale.
My advice is to play with the dtype of your array or, as you mentioned,
resample.
Also, is it needed to keep all images? It sounds to me like your
application will become very resource hungry if you're going to be
displaying several of these 2D images over each other (and if you don't use
transparency, you won't get any benefit at all from plotting them together).
2013年8月27日 Štěpán Turek <ste...@se...>
> Hi,
>
>
> You could, before plotting, sum the different image arrays? Depending on
> whether you are plotting RGB(A) images or greyscale images, you could take
> the sum of the color channels, or take a weighted average.
>
>
> Yes, I will probably merge the images (RGBA) before plotting. I want to
> create more plots and even with this optimization every plot will take 300
> MB... Is there any way how to save some memory?
>
>
> Best
>
> Stepan
>
>
>

Hi,
"
You could, before plotting, sum the different image arrays? Depending on 
whether you are plotting RGB(A) images or greyscale images, you could take 
the sum of the color channels, or take a weighted average. 
"
Yes, I will probably merge the images (RGBA) before plotting. I want to 
create more plots and even with this optimization every plot will take 300 
MB... Is there any way how to save some memory?
Best
Stepan 
 

Le Lun 26 août 2013 18:21, Goyo a écrit :
> 2013年7月19日 Nicolas Mailhot <nic...@la...>:
>> Le Mer 17 juillet 2013 14:56, Michael Droettboom a écrit :
>>> Can you please provide a completely standalone example? The following
>>> code has undefined variables etc.
>>
>> Here it is, I'm afraid this testcase intent is less clear than what I
>> pasted previously (I replaced variables with precomputed values)
>>
>> As shown in the attached png, the bottom tick labels (month names) are
>> missing. It worked in matplotlib ≤ 1.2.0
>
> I can confirm the issue with 1.2.1 but it works with a recent
> development version (output attached) so it must have been fixed at
> some point.
Thank you very much for the data point, I'll try to get 1.3.0 built on RHEL 6
Regards,
-- 
Nicolas Mailhot

You could, before plotting, sum the different image arrays? Depending on
whether you are plotting RGB(A) images or greyscale images, you could take
the sum of the color channels, or take a weighted average.
The method you use here depends strongly on the image type, but it will
reduce memory consumption.
Just a thought.
2013年8月27日 Štěpán Turek <ste...@se...>
> Hi,
>
> I would like to plot multiple overlayed 4096x4096 images in one axes. If I
> run this code the plot takes 300 MB of memory:
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> if __name__ == '__main__':
> img = np.zeros((4096, 4096))
> img[100: 300, 100:1500] = 200
> imgplot = plt.imshow(img)
>
> plt.show()
>
> And it takes additional 300 MB for every image with this size added into
> plot. Is there any way to reduce memory consumption without need of data
> resampling?
>
> My configuration:
> Matplotlib 1.2.1
> Numpy 1.7.1
> Ubuntu 13.04 64 bit
>
> Best
> Stepan
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi,
I would like to plot multiple overlayed 4096x4096 images in one axes. If I 
run this code the plot takes 300 MB of memory:
import numpy as np
import matplotlib.pyplot as plt
if __name__ == '__main__':
  img = np.zeros((4096, 4096))
  img[100: 300, 100:1500] = 200
  imgplot = plt.imshow(img)
  plt.show()
And it takes additional 300 MB for every image with this size added into 
plot. Is there any way to reduce memory consumption without need of data 
resampling?
My configuration:
Matplotlib 1.2.1
Numpy 1.7.1
Ubuntu 13.04 64 bit
Best
Stepan