matplotlib-users Mailing List for matplotlib

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

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

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

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