SourceForge logo
SourceForge logo
Menu

matplotlib-users — Discussion related to using matplotlib

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
(3)
Jun
Jul
Aug
(12)
Sep
(12)
Oct
(56)
Nov
(65)
Dec
(37)
2004 Jan
(59)
Feb
(78)
Mar
(153)
Apr
(205)
May
(184)
Jun
(123)
Jul
(171)
Aug
(156)
Sep
(190)
Oct
(120)
Nov
(154)
Dec
(223)
2005 Jan
(184)
Feb
(267)
Mar
(214)
Apr
(286)
May
(320)
Jun
(299)
Jul
(348)
Aug
(283)
Sep
(355)
Oct
(293)
Nov
(232)
Dec
(203)
2006 Jan
(352)
Feb
(358)
Mar
(403)
Apr
(313)
May
(165)
Jun
(281)
Jul
(316)
Aug
(228)
Sep
(279)
Oct
(243)
Nov
(315)
Dec
(345)
2007 Jan
(260)
Feb
(323)
Mar
(340)
Apr
(319)
May
(290)
Jun
(296)
Jul
(221)
Aug
(292)
Sep
(242)
Oct
(248)
Nov
(242)
Dec
(332)
2008 Jan
(312)
Feb
(359)
Mar
(454)
Apr
(287)
May
(340)
Jun
(450)
Jul
(403)
Aug
(324)
Sep
(349)
Oct
(385)
Nov
(363)
Dec
(437)
2009 Jan
(500)
Feb
(301)
Mar
(409)
Apr
(486)
May
(545)
Jun
(391)
Jul
(518)
Aug
(497)
Sep
(492)
Oct
(429)
Nov
(357)
Dec
(310)
2010 Jan
(371)
Feb
(657)
Mar
(519)
Apr
(432)
May
(312)
Jun
(416)
Jul
(477)
Aug
(386)
Sep
(419)
Oct
(435)
Nov
(320)
Dec
(202)
2011 Jan
(321)
Feb
(413)
Mar
(299)
Apr
(215)
May
(284)
Jun
(203)
Jul
(207)
Aug
(314)
Sep
(321)
Oct
(259)
Nov
(347)
Dec
(209)
2012 Jan
(322)
Feb
(414)
Mar
(377)
Apr
(179)
May
(173)
Jun
(234)
Jul
(295)
Aug
(239)
Sep
(276)
Oct
(355)
Nov
(144)
Dec
(108)
2013 Jan
(170)
Feb
(89)
Mar
(204)
Apr
(133)
May
(142)
Jun
(89)
Jul
(160)
Aug
(180)
Sep
(69)
Oct
(136)
Nov
(83)
Dec
(32)
2014 Jan
(71)
Feb
(90)
Mar
(161)
Apr
(117)
May
(78)
Jun
(94)
Jul
(60)
Aug
(83)
Sep
(102)
Oct
(132)
Nov
(154)
Dec
(96)
2015 Jan
(45)
Feb
(138)
Mar
(176)
Apr
(132)
May
(119)
Jun
(124)
Jul
(77)
Aug
(31)
Sep
(34)
Oct
(22)
Nov
(23)
Dec
(9)
2016 Jan
(26)
Feb
(17)
Mar
(10)
Apr
(8)
May
(4)
Jun
(8)
Jul
(6)
Aug
(5)
Sep
(9)
Oct
(4)
Nov
Dec
2017 Jan
(5)
Feb
(7)
Mar
(1)
Apr
(5)
May
Jun
(3)
Jul
(6)
Aug
(1)
Sep
Oct
(2)
Nov
(1)
Dec
2018 Jan
Feb
Mar
Apr
(1)
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
2020 Jan
Feb
Mar
Apr
May
(1)
Jun
Jul
Aug
Sep
Oct
Nov
Dec
2025 Jan
(1)
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
S M T W T F S



1
(3)
2
(5)
3
(11)
4
5
6
(8)
7
(4)
8
(4)
9
(2)
10
(4)
11
(1)
12
(3)
13
(3)
14
(5)
15
(11)
16
(8)
17
(5)
18
(3)
19
(1)
20
(6)
21
(7)
22
(5)
23
(6)
24
(4)
25
(5)
26
27
(1)
28
(13)
29
(4)
30
(2)
31
(8)

Showing 4 results of 4

From: Colin M. <cj...@co...> - 2013年05月07日 11:48:26
The default backend is macosx but using it leads to the error I mentioned:
Traceback (most recent call last):
 File "./fftest.py", line 24, in <module>
 ani.save('animation.avi')
 File "/Library/Python/2.6/site-packages/matplotlib/animation.py", 
line 615, in save
 writer.grab_frame()
 File "/Library/Python/2.6/site-packages/matplotlib/animation.py", 
line 199, in grab_frame
 dpi=self.dpi)
 File "/Library/Python/2.6/site-packages/matplotlib/figure.py", line 
1370, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/Library/Python/2.6/site-packages/matplotlib/backend_bases.py", line 
2015, in print_figure
 print_method = self._get_print_method(format)
 File 
"/Library/Python/2.6/site-packages/matplotlib/backend_bases.py", line 
1956, in _get_print_method
 '%s.' % (format, ', '.join(formats)))
ValueError: Format "rgba" is not supported.
Supported formats: bmp, emf, eps, gif, jpeg, jpg, pdf, pgf, png, ps, 
raw, rgba, svg, svgz, tif, tiff.
The above error does not occur if I switch to agg.
Also using the ffmpeg command
ffmpeg -f image2 -i t%d.jpg video.avi
on a few images gives the following output, where I put !! next to the 
lines which are suppressed by including -loglevel quiet
FFmpeg version SVN-r26402, Copyright (c) 2000-2011 the FFmpeg developers
 built on May 2 2013 23:13:41 with llvm_gcc 4.2.1 (Based on Apple 
Inc. build 5658) (LLVM build 2336900)
 configuration: --enable-libmp3lame --enable-shared --disable-mmx 
--arch=x86_64
 libavutil 50.36. 0 / 50.36. 0
 libavcore 0.16. 1 / 0.16. 1
 libavcodec 52.108. 0 / 52.108. 0
 libavformat 52.93. 0 / 52.93. 0
 libavdevice 52. 2. 3 / 52. 2. 3
 libavfilter 1.74. 0 / 1.74. 0
 libswscale 0.12. 0 / 0.12. 0
Input #0, image2, from 't%d.jpg':
 Duration: 00:00:00.12, start: 0.000000, bitrate: N/A
 Stream #0.0: Video: mjpeg, yuvj422p, 4272x2848, 25 tbr, 25 tbn, 25 tbc
File 'video.avi' already exists. Overwrite ? [y/N] y
!![buffer @ 0x7fff094014b0] w:4272 h:2848 pixfmt:yuvj422p
!![ffsink @ 0x7fff094016d0] auto-inserting filter 'auto-inserted 
scaler 0' between the filter 'src' and the filter 'out'
!![scale @ 0x7fff094018f0] w:4272 h:2848 fmt:yuvj422p -> w:4272 h:2848 
fmt:yuv420p flags:0x4
!!Output #0, avi, to 'video.avi':
!! Metadata:
!! ISFT : Lavf52.93.0
!! Stream #0.0: Video: mpeg4, yuv420p, 4272x2848, q=2-31, 200 kb/s, 
25 tbn, 25 tbc
Stream mapping:
 Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 3 fps= 2 q=4.0 Lsize= 524kB time=0.12 bitrate=35781.7kbits/s
video:519kB audio:0kB global headers:0kB muxing overhead 1.083673%
Quoting Tony Yu <ts...@gm...>:
> On Mon, May 6, 2013 at 7:09 AM, Colin McAuliffe <cj...@co...>wrote:
>
>> Hi Tony, thanks for the reply.
>>
>> I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists. I
>> ran the example code from the link and it hangs after 350-400 frames. Also,
>> I got an error when running the code as it is posted and had to add:
>>
>> import matplotlib
>> matplotlib.use("Agg")
>>
>> to get it to work. Is this an incorrect setting I'm using?
>>
>> Colin
>
>
> Hmm, that's strange: Your problem sounds too similar to be a different bug.
> Could you copy the error message you got? It might be a clue. Also, what
> backend are you running?
>
>>>> import matplotlib.pyplot as plt
>>>> print plt.rcParams['backend']
>
> Another possibility (longshot) is that your version of `ffmpeg` may not
> respect the `-loglevel quiet` flag being passed to suppress output. Maybe
> you could try running an `ffmpeg` command with and without that flag to see
> if it works.
>
> -Tony
>
-- 
Colin McAuliffe
PhD Candidate
Columbia University
Department of Civil Engineering and Engineering Mechanics
From: Ondřej Č. <ond...@gm...> - 2013年05月07日 05:26:14
On Mon, May 6, 2013 at 6:27 PM, Michael Droettboom <md...@st...> wrote:
> Well, we could try a different approach. matplotlib will use pkg-config to
> find its dependencies, if available.
>
> If you can get your local libpng to include a libpng.pc (i.e. a pkg-config
> information file) and then add your local pkg-config path (probably
> /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/pkgconfig)
> to the PKG_CONFIG_PATH environment variable, it should pick up the right
> name for the library as well.
It works!! Thanks a lot. Here I found the same answer as well:
http://stackoverflow.com/questions/16227285/unable-to-import-matplotlib-png-pylab
> If you get that working, you may be able to
> avoid setting CFLAGS and LDFLAGS explicitly and the Makefile modifications.
Indeed. I definitely don't need Python Makefile modifications and here
is my polished install script now:
export PKG_CONFIG_PATH="$PNG/lib/pkgconfig:$FREETYPE/lib/pkgconfig"
export LDFLAGS="-L$PNG/lib -Wl,-rpath=$PNG/lib"
$PYTHON/bin/python setup.py install
As you can see, I still need to setup the rpath, but that is to be expected.
For the record, here is how _png.o and _png.so end up compiled and linked:
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall
-I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
-fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
-I/usr/local/include -I/usr/include
-I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include/libpng16
-I/usr/local/include -I/usr/include -I.
-I/home/ondrej/repos/python-hpcmp2/opt/numpy/hpbc/lib/python2.7/site-packages/numpy/core/include
-I. -I/home/ondrej/repos/python-hpcmp2/opt/python/llzf/include/python2.7
-c src/_png.cpp -o build/temp.linux-x86_64-2.7/src/_png.o
g++ -pthread -shared -L/usr/lib/x86_64-linux-gnu
-L/lib/x86_64-linux-gnu
-L/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
-L/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-Wl,-rpath=/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
build/temp.linux-x86_64-2.7/src/_png.o
build/temp.linux-x86_64-2.7/src/mplutils.o
build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
build/temp.linux-x86_64-2.7/CXX/cxxextensions.o
-L/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib -L/usr/local/lib
-L/usr/lib -lpng16 -lz -lstdc++ -lm -o
build/lib.linux-x86_64-2.7/matplotlib/_png.so
I think that this looks good. If I need to ever remove the
-L/usr/lib/x86_64-linux-gnu parts, then I just fix the Python package.
Ondrej
From: Tony Yu <ts...@gm...> - 2013年05月07日 03:42:30
On Mon, May 6, 2013 at 7:09 AM, Colin McAuliffe <cj...@co...>wrote:
> Hi Tony, thanks for the reply.
>
> I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists. I
> ran the example code from the link and it hangs after 350-400 frames. Also,
> I got an error when running the code as it is posted and had to add:
>
> import matplotlib
> matplotlib.use("Agg")
>
> to get it to work. Is this an incorrect setting I'm using?
>
> Colin
Hmm, that's strange: Your problem sounds too similar to be a different bug.
Could you copy the error message you got? It might be a clue. Also, what
backend are you running?
>>> import matplotlib.pyplot as plt
>>> print plt.rcParams['backend']
Another possibility (longshot) is that your version of `ffmpeg` may not
respect the `-loglevel quiet` flag being passed to suppress output. Maybe
you could try running an `ffmpeg` command with and without that flag to see
if it works.
-Tony
From: Michael D. <md...@st...> - 2013年05月07日 00:27:33
Well, we could try a different approach. matplotlib will use pkg-config 
to find its dependencies, if available.
If you can get your local libpng to include a libpng.pc (i.e. a 
pkg-config information file) and then add your local pkg-config path 
(probably
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/pkgconfig) 
to the PKG_CONFIG_PATH environment variable, it should pick up the right 
name for the library as well. If you get that working, you may be able 
to avoid setting CFLAGS and LDFLAGS explicitly and the Makefile 
modifications.
Mike
On 05/06/2013 06:53 PM, Ondřej Čertík wrote:
> On Mon, May 6, 2013 at 3:53 PM, Michael Droettboom <md...@st...> wrote:
>> My understanding is that distutils builds up the commandline arguments for
>> gcc in this order:
>>
>> 1) From Python's Makefile.
>> 2) From environment variables
>> 3) From whatever was added by the setup.py script
>>
>> It looks like you have some extra stuff in (1), namely
>>
>> -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
>>
>> You can find the Python Makefile that is being used to source this
>> information here:
>>
>>>>> from distutils import sysconfig
>>>>> sysconfig.get_makefile_filename()
> This gives:
>
> In [1]: from distutils import sysconfig
>
> In [2]: sysconfig.get_makefile_filename()
> Out[2]: '/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/python2.7/config/Makefile'
>
>
>
>> You can edit that file, though obviously that's a bit of a hack.
> It contains the lines:
>
> CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
> LDFLAGS= -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
>
>
> So indeed this is causing it. I think this comes from building our own
> Python, which I do with:
>
> ----------------------
>
> #!/bin/bash
>
> set -e
>
> export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
> export LDFLAGS="-L/usr/lib/$arch -L/lib/$arch"
> export CFLAGS="-I/usr/include/$arch"
> export CPPFLAGS="-I/usr/include/$arch"
> # Fix for #21:
> export HAS_HG="no"
> ./configure --prefix=${PYTHONHPC_PREFIX}
>
> ---------------------------
>
> And this is a bit of a hack too, Ubuntu specific etc. I think I should
> start fixing things here.
>
> It just wouldn't occur to me, that remains of how I built Python would
> bite me later when building
> matplotlib.
>
> So to test if modifying the Python makefile fixes it, I did:
>
> --- Makefile.old 2013年05月06日 16:26:25.426440205 -0600
> +++ Makefile 2013年05月06日 16:27:05.282439550 -0600
> @@ -73,8 +73,8 @@
> # Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py to
> # be able to build extension modules using the directories specified in the
> # environment variables
> -CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
> -LDFLAGS= -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
> +CPPFLAGS= -I. -IInclude -I$(srcdir)/Include
> +LDFLAGS=
> LDLAST=
> SGI_ABI=
> CCSHARED= -fPIC
>
> but mpl build system still shows the system one. The _png.so is built with:
>
> [matplotlib] g++ -pthread -shared
> -L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
> -L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
> -Wl,-rpath=/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
> -I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/include
> -I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
> -I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
> build/temp.linux-x86_64-2.7/src/_png.o
> build/temp.linux-x86_64-2.7/src/mplutils.o
> build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
> build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
> build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
> build/temp.linux-x86_64-2.7/CXX/cxxextensions.o -L/usr/local/lib
> -L/usr/lib -lpng12 -lz -lstdc++ -lm -o
> build/lib.linux-x86_64-2.7/matplotlib/_png.so
>
> Which in my opinion looks good -- my own version of PNG is offered
> first on the gcc command line. But the -lpng12 part spoils it --- that
> forces gcc to use the systemone, because my own version is newer.
>
>
> So I think that part of the problem gets fixed by modifying the Python
> Makefile, but the other part of the problem is how to force distutils
> to look for my PNG version before the systemwide. Any ideas?
>
> Maybe it is something that is added by the mpl setup.py script.
>
>> I've run into this problem before, and there doesn't seem to be any good way
>> around it -- i.e. there doesn't seem to be a way to insert local environment
>> variables in front of the global Python configuration. Reason number #47
>> why distutils is a poor build system for C/C++ code.
> This is amazingly broken.
>
> Ondrej

Showing 4 results of 4

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /