matplotlib-users Mailing List for matplotlib

If I generate a figure, without knowing, a priori, what the size of  
the actual plotted contents (plot, axes, colorbar, etc.) will take up,  
is there an efficient way to figure out that size and then trim the  
figure?

-gideon

I have installed, using Fink commander, freetype2 2.1.3-22.

I have then downloaded the zips of
libpng-1.2.33
matplotlib-0.98.3
ipython-0.8.4
and then built and installed them.

when I run ipython -pylab the ipython aborts with the following:

Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/Current/bin/ 
ipython", line 27, in <module>
     IPython.Shell.start().mainloop()
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/IPython/Shell.py", line 1220, in start
     return shell(user_ns = user_ns)
....etc
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/matplotlib/_png.so, 2): Symbol not found:  
_png_set_palette_to_rgb
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/matplotlib/_png.so
   Expected in: dynamic lookup

I'm running on OSX 10.4.11.  I assume the problem is with the line
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/matplotlib/_png.so, 2): Symbol not found:  
_png_set_palette_to_rgb

Does anyone have any idea what is wrong here?

Thanks,

Garvin.

		
___________________________________________________________ 
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal 
http://uk.docs.yahoo.com/nowyoucan.html

Gideon Simpson <si...@ma...> writes:

>> It looks like it is happening in dviread. Just to make sure this is
>> the culprit, could you temporarily disable usetex in your
>> matplotlibrc file and see if the error goes away?
>
> yes that seems to work.  there are no errors when i don't use the tex.

I tried to fix one possible cause of this in dviread. Can you update to
the latest trunk version and see if you keep having the same problem
with usetex enabled?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Sat, Nov 8, 2008 at 10:39 PM, Jae-Joon Lee <lee...@gm...> wrote:
> John,
> I'm attaching an another patch, which seems to give a correct result
> for the figimage_demo.
> The flipud_out() calls before compositing seems to have no effect, so

Ahh, I think you found the ultimate source of our woes and flupud
complexity: the _image.from_images module was ignoring the stride, as
you noted in the comment in your patch.  I just fixed this n r6381, so
the code behaves properly at the extension code level and we don't
have to do all those confusing flips in the axes or figure compositing
methods.  So the code is now simpler, and it works.

Thanks for digging into this.

JDH

"nicky van foreest" <van...@gm...> writes:

> I try to plot a histogram, which succeeds nicely, but I also get a
> strange line in the same plot. Does anybody know why this is the case,
> and what to do about it? Here  is the code:
>
>     n, bins, patches = hist(res,bins = 10, cumulative=True, normed=False)
>     l = plot(bins)
>     show()

Just omit plot(bins) from your script. The hist function (in pylab)
already draws the histogram, and plot(bins) adds the extra line. Use
numpy.histogram if you just want to compute the histogram.

The docstring of hist says "Compute the histogram of *x*", which is
misleading because it draws the histogram. I'll fix the docstring.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

John Hunter wrote:
> On Thu, Nov 6, 2008 at 4:28 PM, Darren Dale <dar...@co...> wrote:
>
>   
>> Stan West checked out my subprocess patch on windows with python-2.5, which
>> should take care of a bunch of deprecation warnings. I need to double check
>> that I got them all, maybe I can get to it this weekend.
>>
>> I'm in favor of dropping support for python-2.4, but on the other hand I
>> think the most recent version of RHEL still uses this version.
>>     
>
> Actually, we still use 2.4 at work, so I'd like to continue supporting
> 2.4 for a while I guess, for purely selfish reasons.  But perhaps we
> should stop making binaries for it to ease the burden on Charlie.
> Once the 2.6 binaries for numpy are out and we are making binaries for
> the next release, that is....
>   

I think it would be a mistake to stop supporting python 2.4 as well.
RHEL indeed still uses 2.4 as its default python. It would make the
installation of the numpy/mpl stack even harder than it already is on
those platforms, which does not strike me as a good idea (I am a numpy
developer, and I find it already quite difficult). Does python 2.5 have
that many interesting features compared to 2.4 ?

cheers,

David

John,
I'm attaching an another patch, which seems to give a correct result
for the figimage_demo.
The flipud_out() calls before compositing seems to have no effect, so
I deleted those lines. The make_image() routine seems to take care of
the fliping already, but note the comments I added. Let me know if
there are cases this patch does not work.

-JJ




On Sat, Nov 8, 2008 at 7:28 PM, John Hunter <jd...@gm...> wrote:
> On Sat, Nov 8, 2008 at 6:10 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>> My original patch does not work for this case, because the figimage is
>> drawn by Figure.draw() not by Axes.draw() method.
>> I'm attaching a new patch where I applied the same correction to the
>> Figure.draw().
>> I tested GtkAgg, Gtk, GtkCairo, Pdf, Ps and they all worked fine.
>
> So I managed to sneak some time to apply and test these after all --
> but I am getting in a little trouble with my wife :-)
>
> The layer images demo looks great for pdf, svg and png, but I am still
> seeing problems with the figimage_demo for origin "upper".  On svg and
> pdf in my tests, blue still appears down, though is correctly up on
> png.  I went ahead and committed your changes (with a minor variation
> that the list comprehensions are expressed as plain-ol-loops because
> some people consider the use of a list comprehension simply to do in
> place modifications where the list itself is discarded to be an abuse
> of the construct) to revision 6380.
>
> Make sure I didn't screw something up, but the figimage_demo still
> looks broken to me for the case currently in fsvn
>
> Thanks for all the progress!
> JDH
>

Hello list,

I have plotted the following curve:

 from pylab import *
t = arange(0.0, 2.0, 0.01)
s = sin(2*pi*t)
plot(t, s)
grid(True)
show()

The std matplotlib output gives only zoom, pan and save functions. 
I
need to check the distance between two points on the plotted curve 
by
clicking on the curve. How do I do this?

Thanks,
AMaity

Oops!  I had no intention of including matplotlib-users on the address 
list of the preceding message.  It was supposed to be strictly local. 
Sorry for the noise.

Eric

Eric Firing wrote:
> Quite recently the matplotlib web site was redone, with considerable 
> improvements in documentation. If you are interested in matplotlib 
> plotting, check out http://matplotlib.sourceforge.net/.  The "gallery" 
> link has a disorderly collection of examples with source code, so you 

On Sat, Nov 8, 2008 at 6:10 PM, Jae-Joon Lee <lee...@gm...> wrote:

> My original patch does not work for this case, because the figimage is
> drawn by Figure.draw() not by Axes.draw() method.
> I'm attaching a new patch where I applied the same correction to the
> Figure.draw().
> I tested GtkAgg, Gtk, GtkCairo, Pdf, Ps and they all worked fine.

So I managed to sneak some time to apply and test these after all --
but I am getting in a little trouble with my wife :-)

The layer images demo looks great for pdf, svg and png, but I am still
seeing problems with the figimage_demo for origin "upper".  On svg and
pdf in my tests, blue still appears down, though is correctly up on
png.  I went ahead and committed your changes (with a minor variation
that the list comprehensions are expressed as plain-ol-loops because
some people consider the use of a list comprehension simply to do in
place modifications where the list itself is discarded to be an abuse
of the construct) to revision 6380.

Make sure I didn't screw something up, but the figimage_demo still
looks broken to me for the case currently in fsvn

Thanks for all the progress!
JDH

> Hey Jae Joon -- thanks for looking into this.  I don't have time to
> test this patch, but I wanted to mention that there is an analogous
> problem for figure image compositing -- see figimage_demo.py.  agg
> shows the correct behavior: the two images should be in the lower
> left, and the blue should be down for image origin=lower and the blue
> should be up for image origin=upper.  So if you are having success
> with the image compositing orientation problems on the various
> backends, you may want to see if your fixes apply to the figimage
> problems as well.
>

My original patch does not work for this case, because the figimage is
drawn by Figure.draw() not by Axes.draw() method.
I'm attaching a new patch where I applied the same correction to the
Figure.draw().
I tested GtkAgg, Gtk, GtkCairo, Pdf, Ps and they all worked fine.


-JJ