matplotlib-users Mailing List for matplotlib (Page 5)

Yeah -- I can confirm this. I'm not sure what the most desired behavior 
is, but I think it's worth opening a discussion in a Github issue.
Mike
On 05/09/2013 08:44 PM, K.-Michael Aye wrote:
> If someone confirms this, I'd be happy to put it into github, but I
> thought I send it here first, to see if this is another PEBKAC.
>
> Michael
>
>
> On 2013年05月10日 00:39:48 +0000, K.-Michael Aye said:
>
>> Problem: New y-axis max value set by edit-curve interface is forgotten
>> after zoom-in-zoom-out cycle.
>>
>> Reproduction steps:
>>
>> * change y-axis max to a larger value than used by the default layouter
>> with the edit-curve interface (click on the green hook)
>> * Click Ok
>> * Zoom into the plot
>> * click the 'Back' button and see the max on y-axis going back to the
>> default value.
>>
>> I would understand if the Home button goes to the default layout,
>> although that's debatable, but the back button really should go to the
>> previous layout, not the default layout values.
>>
>> Michael
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their applications. This 200-page book is written by three acclaimed
>> leaders in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

From the matplotlib page, you can reach:
http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html
and just translates the function:
def inside_polygon(p, vertices):
 vx,vy = vertices[:,0], vertices[:,1]
 x,y = p
 c = 0
 j = len(vertices)-1
 for i in xrange(len(vertices)):
 if( ((vy[i] > y) != (vy[j] > y)) and (x < (vx[j]-vx[i]) * (y-vy[i]) / (vy[j]-vy[i]) + vx[i]) ):
 c = 1-c
 j = i
 return c
Of course this would be slower than the corresponding C implementation.
Nicolas
On May 9, 2013, at 21:55 , algotr8der wrote:
> I tried to execute the following code:
> 
> http://matplotlib.org/faq/howto_faq.html#test-whether-a-point-is-inside-a-polygon
> 
> However I get errors I describe here:
> 
> http://stackoverflow.com/questions/16452509/matplotlib-pnpoly-example-results-in-error
> 
>>>> import numpy as np
>>>> import matplotlib.nxutils as nx
>>>> verts = np.array([ [0,0], [0, 1], [1, 1], [1,0]], float)
>>>> nx.pnpoly(0.5, 0.5, verts)
> 
> Traceback (most recent call last):
> File "<console>", line 1, in <module>
> File "C:\Python27\lib\site-packages\matplotlib\nxutils.py", line 26, in
> pnpoly
> return p.contains_point(x, y)
> File "C:\Python27\lib\site-packages\matplotlib\path.py", line 289, in
> contains_point
> transform = transform.frozen()
> AttributeError: 'float' object has no attribute 'frozen'
> 
>>>> nx.pnpoly(0.5, 1.5, verts)
> 
> Traceback (most recent call last):
> File "<console>", line 1, in <module>
> File "C:\Python27\lib\site-packages\matplotlib\nxutils.py", line 26, in
> pnpoly
> return p.contains_point(x, y)
> File "C:\Python27\lib\site-packages\matplotlib\path.py", line 289, in
> contains_point
> transform = transform.frozen()
> AttributeError: 'float' object has no attribute 'frozen'
> 
> Apparently, nxutils is deprecated, which to me means it should still work
> but a user on stackoverflow pointed out that there may be some code rot.
> That said, the documentation on matplotlib.path.Path.contains_point is weak
> (see below). Does anyone have an example of how I can do the exact same
> thing in the code in the howto_faq but using the suggested function
> (contains_point)?
> 
> http://matplotlib.org/1.2.1/api/path_api.html?highlight=contains_point#matplotlib.path.Path.contains_point
> 
> contains_point(point, transform=None, radius=0.0)
> 
> Returns True if the path contains the given point.
> If transform is not None, the path will be transformed before performing
> the test.
> radius allows the path to be made slightly larger or smaller.
> 
> contains_points(points, transform=None, radius=0.0)
> 
> Returns a bool array which is True if the path contains the
> corresponding point.
> If transform is not None, the path will be transformed before performing
> the test.
> radius allows the path to be made slightly larger or smaller.
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://matplotlib.1069221.n5.nabble.com/re-matplotlib-pnpoly-example-results-in-error-tp41028.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their applications. This 200-page book is written by three acclaimed 
> leaders in the field. The early access version is available now. 
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

If someone confirms this, I'd be happy to put it into github, but I 
thought I send it here first, to see if this is another PEBKAC.
Michael
On 2013年05月10日 00:39:48 +0000, K.-Michael Aye said:
> Problem: New y-axis max value set by edit-curve interface is forgotten
> after zoom-in-zoom-out cycle.
> 
> Reproduction steps:
> 
> * change y-axis max to a larger value than used by the default layouter
> with the edit-curve interface (click on the green hook)
> * Click Ok
> * Zoom into the plot
> * click the 'Back' button and see the max on y-axis going back to the
> default value.
> 
> I would understand if the Home button goes to the default layout,
> although that's debatable, but the back button really should go to the
> previous layout, not the default layout values.
> 
> Michael
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Problem: New y-axis max value set by edit-curve interface is forgotten 
after zoom-in-zoom-out cycle.
Reproduction steps:
* change y-axis max to a larger value than used by the default layouter 
with the edit-curve interface (click on the green hook)
* Click Ok
* Zoom into the plot
* click the 'Back' button and see the max on y-axis going back to the 
default value.
I would understand if the Home button goes to the default layout, 
although that's debatable, but the back button really should go to the 
previous layout, not the default layout values.
Michael

I tried to execute the following code:
http://matplotlib.org/faq/howto_faq.html#test-whether-a-point-is-inside-a-polygon
However I get errors I describe here:
http://stackoverflow.com/questions/16452509/matplotlib-pnpoly-example-results-in-error
>>>import numpy as np
>>>import matplotlib.nxutils as nx
>>>verts = np.array([ [0,0], [0, 1], [1, 1], [1,0]], float)
>>>nx.pnpoly(0.5, 0.5, verts)
Traceback (most recent call last):
 File "<console>", line 1, in <module>
 File "C:\Python27\lib\site-packages\matplotlib\nxutils.py", line 26, in
pnpoly
 return p.contains_point(x, y)
 File "C:\Python27\lib\site-packages\matplotlib\path.py", line 289, in
contains_point
 transform = transform.frozen()
AttributeError: 'float' object has no attribute 'frozen'
>>>nx.pnpoly(0.5, 1.5, verts)
Traceback (most recent call last):
 File "<console>", line 1, in <module>
 File "C:\Python27\lib\site-packages\matplotlib\nxutils.py", line 26, in
pnpoly
 return p.contains_point(x, y)
 File "C:\Python27\lib\site-packages\matplotlib\path.py", line 289, in
contains_point
 transform = transform.frozen()
AttributeError: 'float' object has no attribute 'frozen'
Apparently, nxutils is deprecated, which to me means it should still work
but a user on stackoverflow pointed out that there may be some code rot.
That said, the documentation on matplotlib.path.Path.contains_point is weak
(see below). Does anyone have an example of how I can do the exact same
thing in the code in the howto_faq but using the suggested function
(contains_point)?
http://matplotlib.org/1.2.1/api/path_api.html?highlight=contains_point#matplotlib.path.Path.contains_point
contains_point(point, transform=None, radius=0.0)
 Returns True if the path contains the given point.
 If transform is not None, the path will be transformed before performing
the test.
 radius allows the path to be made slightly larger or smaller.
contains_points(points, transform=None, radius=0.0)
 Returns a bool array which is True if the path contains the
corresponding point.
 If transform is not None, the path will be transformed before performing
the test.
 radius allows the path to be made slightly larger or smaller.
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/re-matplotlib-pnpoly-example-results-in-error-tp41028.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

ImageGrid creates axes for colobar even if cbar_mode=None. These axes for
colorbar are set to invisible, so usually they are harmless.
tight_layout, however, do not care whether the axes is visible or not, and
the warning is because of these "invisible" axes for colorbars.
For comparison, if you turn on all colorbar with cbar_mode="each", the
warning will go away.
You may manually remove colorbar axes from the figure if you want,
```
for ax in grid.cbar_axes: fig._axstack.remove(ax)
```
but do this only when cbar_mode=None.
So, I think the warning is harmless.
I will make a pull request that make tight_layout to ignore any invisible
axes soon.
Regards,
-JJ
On Wed, May 8, 2013 at 10:21 PM, Jonathan Slavin <js...@cf...>wrote:
> Hi,
>
> I wrote a short routine to look through a set of images that result from
> slightly different processing of the same data. I want to compare three
> different images and be able to zoom them all in the same way and then
> move onto the next set of three. The best way that I've found to do
> that so far involves using mpl_toolkits.axes_grid1.ImageGrid. It all
> works fine. I found that to get the most image on screen at once, using
> the tight_layout=True argument to plt.figure gives excellent results.
> My one question is that I get the following warning:
>
> WARNING: This figure includes Axes that are not compatible with
> tight_layout, so its results might be incorrect. [matplotlib.figure]
>
> As I say, the results are good, so it's not really a problem, but I do
> wonder about the source of the warngin -- and whether re-using the code
> in a different way in the future could lead to problems. So, my
> question is: what is the problem pointed to by the warning and how could
> I avoid it (while still getting the same good results)?
>
> Regards,
> Jon
> --
> ______________________________________________________________
> Jonathan D. Slavin Harvard-Smithsonian CfA
> js...@cf... 60 Garden Street, MS 83
> phone: (617) 496-7981 Cambridge, MA 02138-1516
> cell: (781) 363-0035 USA
> ______________________________________________________________
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi,
I am trying to produce a set of plots using grispec. There should be an images shown in each of the axes (using imshow) except in one of the axes, where I want to show/plot some text. However, the text seems to be too long to be displayed in one line. Is there a way to print it in something like a text box? 
I created a minimal example (see below)
I can not / do not want to make a string variable with three quotation marks (docstring), because I am reading the text from a bigger ascii file.
Thanks for your help!
import matplotlib.pyplot as plt
import matplotlib.gridspec as gridspec
def main():
 """
 goal is to show justified text in one axes of matplotlib
 there are two examples I found on stackoverflow. But I am not sure how they could be applicable here
 http://stackoverflow.com/questions/5777576/is-there-a-way-of-drawing-a-caption-box-in-matplotlib
 http://stackoverflow.com/questions/4018860/text-box-in-matplotlib
 """
 plt.close('all')
 fig = plt.figure(figsize=(5, 10))
 plt.subplots_adjust(left=0.1, right=0.9, top=0.95, bottom=0.1)
 n_rows = 5
 outer_grid = gridspec.GridSpec(n_rows, 2 )# ,wspace=0.0, hspace=0.0
 
 lst_files = [ 'circle.png'
 , 'circle.png'
 , 'circle.png'
 , 'circle.png'
 , 'text'
 , 'circle.png'
 , 'circle.png'
 , 'circle.png'
 , 'circle.png']
 for cur_map_id, cur_map_file in enumerate(lst_files):
 
 cur_row = (cur_map_id % n_rows)
 if cur_map_id / n_rows == 0:
 cur_column = 0
 else:
 cur_column = 1
 
 # preparation: no axes
 ax = plt.subplot(outer_grid[cur_row, cur_column], frameon=False)
 ax.axes.get_yaxis().set_visible(False)
 ax.axes.get_xaxis().set_visible(False)
 
 # fix for the fact that the fourth entry is text and not in tmp_lst_imgs
 if cur_map_id > 4: 
 cur_map_id = cur_map_id - 1
 
 # the actual plotting
 if cur_map_file == 'text':
 lorem = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.'
 ax.text(0.05, 0.9, lorem, size=6)
 else:
 print cur_map_id
 im = plt.imread(cur_map_file)
 ax.imshow(im)
 ax.set_title(cur_map_file, size=6)
 fig.add_subplot(ax)
 
 plt.savefig('blah.png', dpi=300)
 print "done!"
 
if __name__ == '__main__':
 main() 

Hi,
I wrote a short routine to look through a set of images that result from
slightly different processing of the same data. I want to compare three
different images and be able to zoom them all in the same way and then
move onto the next set of three. The best way that I've found to do
that so far involves using mpl_toolkits.axes_grid1.ImageGrid. It all
works fine. I found that to get the most image on screen at once, using
the tight_layout=True argument to plt.figure gives excellent results.
My one question is that I get the following warning:
WARNING: This figure includes Axes that are not compatible with
tight_layout, so its results might be incorrect. [matplotlib.figure]
As I say, the results are good, so it's not really a problem, but I do
wonder about the source of the warngin -- and whether re-using the code
in a different way in the future could lead to problems. So, my
question is: what is the problem pointed to by the warning and how could
I avoid it (while still getting the same good results)?
Regards,
Jon
-- 
______________________________________________________________
Jonathan D. Slavin Harvard-Smithsonian CfA
js...@cf... 60 Garden Street, MS 83
phone: (617) 496-7981 Cambridge, MA 02138-1516
 cell: (781) 363-0035 USA
______________________________________________________________

Hi all,
I discovered recently that basmap does not draw the coastline contours
properly for some choice of map boundaries. Specifically,
from mpl_toolkits.basemap import Basemap
map =
Basemap(projection='cyl',llcrnrlat=-22.,urcrnrlat=22.,llcrnrlon=78.,urcrnrlon=168.,resolution='l')
map.drawcoastlines()
results in the coastline of continental Asia not being drawn (see
attachment bad_contours.png). On the other hand, even subtly changing
the latitude boundaries, to
map =
Basemap(projection='cyl',llcrnrlat=-22.001,urcrnrlat=22.001,llcrnrlon=78.,urcrnrlon=168.,resolution='l')
results in all the coastlines being drawn (see attachment
good_contours.png). I presume this is a bug?
Here is my system info:
Operating system: Linux 3.2.0-41-generic #66-Ubuntu SMP Thu Apr 25
03:27:11 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Matplotlib version: 1.1.0
Where I obtained matplotlib: SourceForge
Customizations to matplotlibrc: none
Thanks,
Sourish

I want to increase the default setting of saved matplotlib graphs, so I
created a file ~/.matplotlib/matplotlibrc containing the line
savefigdpi : 300
I then created a test notebook containing a single cell with the contents
import numpy as np
import matplotlib.pyplot as plt
x = np.array([1,2,3])
y = np.array([4,5,6])
plt.plot(x,y)
plt.savefig('d0.png')
plt.savefig('d300.png',dpi=300)
When I run this within the notebook, the two png files are created fine,
but have different sizes. When I run the same code from the command line
(after saving the same commands to a script file testplot.py), using
ipython testplot.py
the two graphs have the same size, as desired. Does matplotlib ignore the
contents of ~/.matplotlib/matplotlibrc when called from an Ipython
notebook?
By the way, this is using matplotlib 1.2.0 and Ipython 0.13.2, if it makes
any difference.
Thanks for any help.
Richard Stanton

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

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

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

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()
You can edit that file, though obviously that's a bit of a hack.
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.
Mike
On 05/06/2013 05:03 PM, Ondřej Čertík wrote:
> On Mon, May 6, 2013 at 7:18 AM, Michael Droettboom <md...@st...> wrote:
>> On 05/03/2013 02:41 PM, Ondřej Čertík wrote:
>>> Hi,
>>>
>>> As part of building matplotlib for the one python based distribution [1],
>>> I want to always link against our own version of libpng, even if there
>>> is some other systemwide version available. I am on linux (Ubuntu).
>>>
>>> Currently, here is what I am doing:
>>>
>>> CFLAGS="-I$PNG/include -I$FREETYPE/include
>>> -I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
>>> -Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
>>> $PYTHON/bin/python setup.py install
>> This *should* work. Can you provide a full build log of a clean build?
> Sure:
>
> https://gist.github.com/certik/5528134
>
> The build was produced by the "build.sh" script, also in the gist.
>
> On the line 48 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L48)
> you can see where our own PNG lib is:
>
> [matplotlib] lrwxrwxrwx 1 ondrej cnls 11 May 3 11:48
> /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng.so
> -> libpng16.so
> [matplotlib] lrwxrwxrwx 1 ondrej cnls 18 May 3 11:48
> /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng16.so
> -> libpng16.so.16.2.0
>
> as printed by the line 5 in build.sh:
>
> echo "Our PNG library:"
> ls -l $PNG/lib/libpng*.so
>
>
> The actual mpl build starts at the line 52
> (https://gist.github.com/certik/5528134#file-mpl_log-txt-L52). As you
> can see, it found the systemwide PNG lib:
>
> [matplotlib] OPTIONAL BACKEND DEPENDENCIES
> [matplotlib] libpng: 1.2.46
>
> and just to verify this, at the line 2636
> (https://gist.github.com/certik/5528134#file-mpl_log-txt-L2636) I
> print:
>
> echo "The linked PNG library:"
> ldd $PYTHON/lib/python2.7/site-packages/matplotlib/_png.so
>
> which gives:
>
> [matplotlib] The linked PNG library:
> [matplotlib] linux-vdso.so.1 => (0x00007fffd8bc1000)
> [matplotlib] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
> (0x00007f1fd0c0a000)
> [matplotlib] libstdc++.so.6 =>
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1fd090a000)
> [matplotlib] libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x00007f1fd06f3000)
> [matplotlib] libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f1fd04d6000)
> [matplotlib] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1fd0117000)
> [matplotlib] libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1fcfeff000)
> [matplotlib] libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1fcfc03000)
> [matplotlib] /lib64/ld-linux-x86-64.so.2 (0x00007f1fd107e000)
>
> So the systemwide png /lib/x86_64-linux-gnu/libpng12.so.0 is linked instead:
>
> ondrej@kittiwake:~$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0
> lrwxrwxrwx 1 root root 18 Apr 5 2012
> /lib/x86_64-linux-gnu/libpng12.so.0 -> libpng12.so.0.46.0
>
> as you can see, it is exactly the one as advertised by the mpl build
> info above. So the mpl build seems consistent,
> and the bug is that it finds the systemwide version before our own version.
>
> Ondrej

On Mon, May 6, 2013 at 7:18 AM, Michael Droettboom <md...@st...> wrote:
> On 05/03/2013 02:41 PM, Ondřej Čertík wrote:
>> Hi,
>>
>> As part of building matplotlib for the one python based distribution [1],
>> I want to always link against our own version of libpng, even if there
>> is some other systemwide version available. I am on linux (Ubuntu).
>>
>> Currently, here is what I am doing:
>>
>> CFLAGS="-I$PNG/include -I$FREETYPE/include
>> -I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
>> -Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
>> $PYTHON/bin/python setup.py install
> This *should* work. Can you provide a full build log of a clean build?
Sure:
https://gist.github.com/certik/5528134
The build was produced by the "build.sh" script, also in the gist.
On the line 48 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L48)
you can see where our own PNG lib is:
[matplotlib] lrwxrwxrwx 1 ondrej cnls 11 May 3 11:48
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng.so
-> libpng16.so
[matplotlib] lrwxrwxrwx 1 ondrej cnls 18 May 3 11:48
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng16.so
-> libpng16.so.16.2.0
as printed by the line 5 in build.sh:
echo "Our PNG library:"
ls -l $PNG/lib/libpng*.so
The actual mpl build starts at the line 52
(https://gist.github.com/certik/5528134#file-mpl_log-txt-L52). As you
can see, it found the systemwide PNG lib:
[matplotlib] OPTIONAL BACKEND DEPENDENCIES
[matplotlib] libpng: 1.2.46
and just to verify this, at the line 2636
(https://gist.github.com/certik/5528134#file-mpl_log-txt-L2636) I
print:
echo "The linked PNG library:"
ldd $PYTHON/lib/python2.7/site-packages/matplotlib/_png.so
which gives:
[matplotlib] The linked PNG library:
[matplotlib] linux-vdso.so.1 => (0x00007fffd8bc1000)
[matplotlib] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x00007f1fd0c0a000)
[matplotlib] libstdc++.so.6 =>
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1fd090a000)
[matplotlib] libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f1fd06f3000)
[matplotlib] libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f1fd04d6000)
[matplotlib] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1fd0117000)
[matplotlib] libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1fcfeff000)
[matplotlib] libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1fcfc03000)
[matplotlib] /lib64/ld-linux-x86-64.so.2 (0x00007f1fd107e000)
So the systemwide png /lib/x86_64-linux-gnu/libpng12.so.0 is linked instead:
ondrej@kittiwake:~$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0
lrwxrwxrwx 1 root root 18 Apr 5 2012
/lib/x86_64-linux-gnu/libpng12.so.0 -> libpng12.so.0.46.0
as you can see, it is exactly the one as advertised by the mpl build
info above. So the mpl build seems consistent,
and the bug is that it finds the systemwide version before our own version.
Ondrej

On 05/03/2013 02:41 PM, Ondřej Čertík wrote:
> Hi,
>
> As part of building matplotlib for the one python based distribution [1],
> I want to always link against our own version of libpng, even if there
> is some other systemwide version available. I am on linux (Ubuntu).
>
> Currently, here is what I am doing:
>
> CFLAGS="-I$PNG/include -I$FREETYPE/include
> -I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
> -Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
> $PYTHON/bin/python setup.py install
This *should* work. Can you provide a full build log of a clean build?
Mike

 Dear Python users,
I am having difficulty with numerically scaling to match line coordinates vs grid cell size coordinates. I want to calculate the following function: F = distance_of_crossed_line x intersected_cell_value
The problem here is that when I calculate crossed_line_length in line coordinates that will unmatch vs grid coordinate, which is also another x,y with step e.g., dx=dy=2.5 each grid size. I want to do numerical calculation , say, F(distance, intersected_grid_value) function where, intersected_grid_value - values in intersected grid, distance - intersected_line_length (given below or can be found http://stackoverflow.com/questions/16377826/distance-for-each-intersected-points-of-a-line-in-increased-order-in-2d-coordina )
import numpy as np
import scipy as sp
def distance_of_crossed_line(x0, x1, y0, y1):
    # slope
    m = (y1 - y0) / (x1 - x0)
    # Boundary of the selected points
    x_ceil = np.ceil(min(x0, x1))
    x_floor = np.floor(max(x0, x1))
    y_ceil = np.ceil(min(y0, y1))
    y_floor = np.floor(max(y0, y1))
    # calculate all intersected x coordinate
    x = np.arange(x_ceil, x_floor + 1)
    y = m * (x - x0) + y0
    ax = zip(x, y)
    # calculate all intersected y coordinate
    y = np.arange(y_ceil, y_floor + 1)
    x = (y - y0) / m + x0
    ax.extend(zip(x, y))
    ax.append((x0, y0))
    ax.append((x1, y1))
    ax.sort()
    # Transpose
    ax = np.array(ax).T
    # Calculate difference of intersections in X
    dist_x = np.diff(ax[0])
    # Calculate difference of intersections in Y
    dist_y = np.diff(ax[1])
    return np.sqrt(dist_x**2 + dist_y**2)
# PLEASE, note that line points are different from 2D array axis. they should be matched with each other. 
# 2D array.
d_array = np.array[[4.5, 4.5, 4.5, 3.4, 2.5],[ 3.9, 4.5, 5.2, 4.5, 3.4],[3.9, 3.9, 2.5, 2.2, 1.9]]
# Two sample points as a line
x = np.array([ -80, -40 ])
y = np.array([ 60, 55 ])
# The problem: 
F = intersected_line_length * array_grid_values_where_line_crossed_area
* It is not necessary for me to overlay lines onto grid cells properly, JUST, I need to calculate numerically accurate F function Thanks for the answer and guidance in advance,
-- 
Bakhtiyor Zokhidov

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
Quoting Tony Yu <ts...@gm...>:
> On Sun, May 5, 2013 at 7:12 PM, Colin McAuliffe <cj...@co...>wrote:
>
>> Hello all,
>>
>> I'm having an issue with FuncAnimation with ffmpeg. For a small number
>> of frames everything works fine, but for some reason with more than
>> 600 frames the program hangs indefinitely. Is there some kind of frame
>> limit for FuncAmimation or is there a mistake in the arguements I am
>> passing?
>>
>
> Hi Colin,
>
> Which version of Matplotlib are you running? This sounds similar to a bug
> addressed by the following change:
>
> https://github.com/matplotlib/matplotlib/pull/989
>
> This change has already made it into the current release (v1.2).
>
> Best,
> -Tony
>
-- 
Colin McAuliffe
PhD Candidate
Columbia University
Department of Civil Engineering and Engineering Mechanics

On Sun, May 5, 2013 at 7:12 PM, Colin McAuliffe <cj...@co...>wrote:
> Hello all,
>
> I'm having an issue with FuncAnimation with ffmpeg. For a small number
> of frames everything works fine, but for some reason with more than
> 600 frames the program hangs indefinitely. Is there some kind of frame
> limit for FuncAmimation or is there a mistake in the arguements I am
> passing?
>
Hi Colin,
Which version of Matplotlib are you running? This sounds similar to a bug
addressed by the following change:
https://github.com/matplotlib/matplotlib/pull/989
This change has already made it into the current release (v1.2).
Best,
-Tony

Hello all,
I'm having an issue with FuncAnimation with ffmpeg. For a small number 
of frames everything works fine, but for some reason with more than 
600 frames the program hangs indefinitely. Is there some kind of frame 
limit for FuncAmimation or is there a mistake in the arguements I am 
passing?
ani = ani.FuncAnimation(fig, animate,np.range(1,700), 
interval=25,blit=True, init_func=init)
Thanks and all the best
Colin
-- 
Colin McAuliffe
PhD Candidate
Columbia University
Department of Civil Engineering and Engineering Mechanics

On Fri, May 3, 2013 at 12:41 PM, Ondřej Čertík <ond...@gm...> wrote:
> Hi,
>
> As part of building matplotlib for the one python based distribution [1],
I meant to say "for one python distribution", not "the one"...
Ondrej

Hi,
As part of building matplotlib for the one python based distribution [1],
I want to always link against our own version of libpng, even if there
is some other systemwide version available. I am on linux (Ubuntu).
Currently, here is what I am doing:
CFLAGS="-I$PNG/include -I$FREETYPE/include
-I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
-Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
$PYTHON/bin/python setup.py install
Where $PNG and $FREETYPE points to our own versions. On a computer
with no systemwide version of png, this works great. Question:
1) If I don't specify the -rpath option, then libpng.so will fail to
be found at runtime. Is there any other recommended way to go around
this? I don't want to use LD_LIBRARY_PATH.
On a computer with systemwide version available, unfortunately the
systemwide version gets picked up instead. I think it's because of
this:
pkg-config --libs --cflags libpng
-I/usr/include/libpng12 -lpng12
so matplotlib simply calls this (right?) and uses the systemwide
version. Question:
2) How do I force matplotlib to use my own version instead?
I would highly appreciate any input, especially on 2). We have our own
issue open for this at [2] if you are interested for the background.
The merged mpl PR [3] is a little related, but doesn't answer my
questions.
Thanks,
Ondrej
[1] https://github.com/hashdist/python-hpcmp2/
[2] https://github.com/hashdist/python-hpcmp2/issues/53
[3] https://github.com/matplotlib/matplotlib/pull/1884

H, I'm using sfmath, too. I actually wrote a helper function to switch fonts. The preambles are the result of long-term trial and error. Normally, my preambles include some more custom commands which I left out here because they would be distracting. I always wondered why matplotlib doesn't do this kind of font switching out of the box.
def setfont(font=font_default,unicode=True):
 r"""
 Set Matplotlibs rcParams to use LaTeX for font rendering.
 Revert all changes by calling rcdefault() from matplotlib.
 
 Parameters:
 -----------
 font: string
 "Helvetica"
 "Times"
 "Computer Modern"
 
 usetex: Boolean
 Use unicode. Default: False. 
 """
 
 # Use TeX for all figure text!
 plt.rc('text', usetex=True)
 font = font.lower().replace(" ","")
 if font == 'times':
 # Times
 font = {'family':'serif', 'serif':['Times']}
 preamble = r"""
 \usepackage{color}
 \usepackage{mathptmx}
 """
 elif font == 'helvetica':
 # Helvetica
 # set serif, too. Otherwise setting to times and then
 # Helvetica causes an error.
 font = {'family':'sans-serif','sans-serif':['Helvetica'],
 'serif':['cm10']}
 preamble = r"""
 \usepackage{color}
 \usepackage[tx]{sfmath}
 \usepackage{helvet}
 """
 else:
 # Computer modern serif
 font = {'family':'serif', 'serif':['cm10']}
 preamble = r"""
 \usepackage{color}
 """
 
 if unicode:
 # Unicode for Tex
 #preamble = r"""\usepackage[utf8]{inputenc}""" + preamble
 # inputenc should be set automatically
 plt.rcParams['text.latex.unicode']=True
 
 #print font, preamble
 plt.rc('font',**font)
 plt.rcParams['text.latex.preamble'] = preamble
Am 03.05.2013 um 16:08 schrieb Juergen Hasch <py...@el...>:
>> 
>> The solution I use when I want all sans-serif out of TeX is to use the cmbright package, which can be turned on by adding:
>> 
>> rc('text.latex', preamble=r'\usepackage{cmbright}')
>> 
>> That may require installing the cmbright LaTeX package if you don't already have it.
> 
> I am using the sfmath package for this purpose.
> 
> There is a nice comparision of the different approaches to get sans-serif math fonts at the bottom of the sfmath page: 
> http://dtrx.de/od/tex/sfmath.html
> 
> 
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users