matplotlib-users Mailing List for matplotlib (Page 6)

On 03/15/2011 11:47 AM, Tom Dimiduk wrote:
> Ah thanks.  I am used to the general math/physics convention of x axis
> being first.  Caught between conventions I guess.  Good to know why
> things are done differently.
>
> I am using the mouse click event.xdata and event.ydata as indexes into
> an array.  From what you say, it looks like I want to use
> im[im.shape[1]-y, x] to get the pixel a user clicked on.  Is that correct?

Almost--but mpl is using an inverted Y-axis so that the y-coordinate 
increases downward.  Therefore you need only im[round(y), round(x)].

Eric

>
> Thanks agaian,
> Tom
>
> On 03/15/2011 05:35 PM, Eric Firing wrote:
>> On 03/15/2011 10:23 AM, Tom Dimiduk wrote:
>>> It appears to me that when imshow tells you that the mouse cursor is at
>>> x=50, y=100
>>>
>>> That corresponds to array element
>>> im[100, 50]
>>>
>>> Is there a reason imshow does not have x be the first coordinate of the
>>> array as I would think of as conventional usage?
>>
>> That is not conventional usage.  Instead, for images, it common for the
>> image to correspond to a printout of memory, using the C convention.
>> Hence the column index is X, and incrementing the row index yields the
>> next line down on the page, thereby corresponding to a decrease in the Y
>> coordinate.
>>
>> Eric
>>
>>>
>>> Tom
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ah thanks.  I am used to the general math/physics convention of x axis 
being first.  Caught between conventions I guess.  Good to know why 
things are done differently.

I am using the mouse click event.xdata and event.ydata as indexes into 
an array.  From what you say, it looks like I want to use
im[im.shape[1]-y, x] to get the pixel a user clicked on.  Is that correct?

Thanks agaian,
Tom

On 03/15/2011 05:35 PM, Eric Firing wrote:
> On 03/15/2011 10:23 AM, Tom Dimiduk wrote:
>> It appears to me that when imshow tells you that the mouse cursor is at
>> x=50, y=100
>>
>> That corresponds to array element
>> im[100, 50]
>>
>> Is there a reason imshow does not have x be the first coordinate of the
>> array as I would think of as conventional usage?
>
> That is not conventional usage.  Instead, for images, it common for the
> image to correspond to a printout of memory, using the C convention.
> Hence the column index is X, and incrementing the row index yields the
> next line down on the page, thereby corresponding to a decrease in the Y
> coordinate.
>
> Eric
>
>>
>> Tom
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 03/15/2011 10:23 AM, Tom Dimiduk wrote:
> It appears to me that when imshow tells you that the mouse cursor is at
> x=50, y=100
>
> That corresponds to array element
> im[100, 50]
>
> Is there a reason imshow does not have x be the first coordinate of the
> array as I would think of as conventional usage?

That is not conventional usage.  Instead, for images, it common for the 
image to correspond to a printout of memory, using the C convention. 
Hence the column index is X, and incrementing the row index yields the 
next line down on the page, thereby corresponding to a decrease in the Y 
coordinate.

Eric

>
> Tom

It appears to me that when imshow tells you that the mouse cursor is at
x=50, y=100

That corresponds to array element
im[100, 50]

Is there a reason imshow does not have x be the first coordinate of the 
array as I would think of as conventional usage?

Tom

Can you provide a standalone example?  This below is missing some 
imports and there are some mystery variables.

Mike

On 03/15/2011 12:25 PM, Auré Gourrier wrote:
> import matplotlib as mpl
> from matplotlib import pylab
> import numpy as np
>
> #build custom colormap
> cm_sym =customfunc()
>
> #define mesh grid
> theta = np.arange(0.,2.*math.pi+2.*math.pi/9,2.*math.pi/9)
> r = np.arange(0,1.1,0.1)
> X,Y = np.meshgrid(r,theta)
>
> #define rgba array
> polarcolorseq = mpl.cm.ScalarMappable(cmap=cm_hsvsym).to_rgba(Y)
> #set an increasing alpha value along the radius
> polarcolorseq[:,:,-1] = [list(np.arange(0,1.1,.1))]*10
>
> pylab.figure(figsize=(10,5),dpi=100,facecolor='white')
>
> #display using rectangular axis
> ax = pylab.subplot((121),axisbg='k')
> ax.imshow(np.flipud(np.swapaxes(polarcolorseq,0,1)))
>
> #display using polar axis
> ax2 = pylab.subplot((122),axisbg='k',projection='polar')    #also 
> tried with polar=True
> ax2.imshow(np.flipud(np.swapaxes(polarcolorseq,0,1)))
>
> pylab.draw()


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Really  no one to point me in the right direction ?
This is really important, I'm trying to wrap up a publication and this is the 
only element missing...




________________________________
De : Auré Gourrier <aur...@ya...>
À : mat...@li...
Envoyé le : Jeu 10 mars 2011, 15h 40min 04s
Objet : [Matplotlib-users] alternative to imshow with polar axes ?


Dear all,

Once again, I turn for help.
I'm trying to plot a polar image using colormap values for the theta values and 
increasing alpha values along the radius.
I do this using imshow passing the rgba tuple at each pixel position which works 
very nicely with rectangular axes, but fails to display using polar axes (see 
code below). 

As usual, I've done a fair bit of digging to find where the problem is and 
whether I could make out an alternate solution but haven't managed to come 
through. I've tried using pcolormesh but I don't see how to pass the rgba tuple
Can anyone point me in the right direction.
I'm using matplotlib 1.0.1 and Python 2.4

Cheers,

Auré

------
import matplotlib as mpl
from matplotlib import pylab
import numpy as  np

#build custom colormap
cm_sym =customfunc()

#define mesh grid
theta = np.arange(0.,2.*math.pi+2.*math.pi/9,2.*math.pi/9)
r = np.arange(0,1.1,0.1)
X,Y = np.meshgrid(r,theta)

#define rgba array
polarcolorseq = mpl.cm.ScalarMappable(cmap=cm_hsvsym).to_rgba(Y)
#set an increasing alpha value along the radius
polarcolorseq[:,:,-1] = [list(np.arange(0,1.1,.1))]*10

pylab.figure(figsize=(10,5),dpi=100,facecolor='white')

#display using rectangular axis
ax = pylab.subplot((121),axisbg='k')
ax.imshow(np.flipud(np.swapaxes(polarcolorseq,0,1)))

#display using polar axis
ax2 = pylab.subplot((122),axisbg='k',projection='polar')    #also tried with 
polar=True
ax2.imshow(np.flipud(np.swapaxes(polarcolorseq,0,1)))

pylab.draw()        


      

On 3/15/2011 8:51 AM, Michael Droettboom wrote:
> It has no way of deducing the file format from the file object.

Inspect f.name?

Alan Isaac

My fault, I didn't read the docstring properly. Thanks for both replies.

Best,

G

On 15/03/2011 13:51, Michael Droettboom wrote:
> It has no way of deducing the file format from the file object.
>
> You need to explicitly pass the format keyword to savefig, e.g.:
>
>     savefig(f, format='pdf')
>
> Mike
>
> On 03/15/2011 07:11 AM, Giovanni Luca Ciampaglia wrote:
>> Hi all,
>> I call savefig by passing to it a file-like object but it appears to not
>> get the graphics format right:
>>
>> f = open('not_a_pdf.pdf', 'w')
>> plot([1,2,3])
>> savefig(f)
>>
>> but it produces a PNG image. Can anybody confirm this? I am on
>> matplotlib 0.99.3
>>
>> Cheers,
>>
>> Giovanni
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

It has no way of deducing the file format from the file object.

You need to explicitly pass the format keyword to savefig, e.g.:

   savefig(f, format='pdf')

Mike

On 03/15/2011 07:11 AM, Giovanni Luca Ciampaglia wrote:
> Hi all,
> I call savefig by passing to it a file-like object but it appears to not
> get the graphics format right:
>
> f = open('not_a_pdf.pdf', 'w')
> plot([1,2,3])
> savefig(f)
>
> but it produces a PNG image. Can anybody confirm this? I am on
> matplotlib 0.99.3
>
> Cheers,
>
> Giovanni
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi all,
I call savefig by passing to it a file-like object but it appears to not 
get the graphics format right:

f = open('not_a_pdf.pdf', 'w')
plot([1,2,3])
savefig(f)

but it produces a PNG image. Can anybody confirm this? I am on 
matplotlib 0.99.3

Cheers,

Giovanni

Hi all,
I call savefig by passing to it a file-like object but it appears to not 
get the graphics format right:

f = open('not_a_pdf.pdf', 'w')
plot([1,2,3])
savefig(f)

but it produces a PNG image. Can anybody confirm this? I am on 
matplotlib 0.99.3

Cheers,
-- 
Giovanni L. Ciampaglia
PhD Student
University of Lugano, MACS Lab

I'm plotting a series of sub plots within a figure, where most are small sub
plots, but the last one spans the width of the figure. For the final subplot
only, I want to set the xtick pad to 20. Something like:


import matplotlib.pyplot as plt

fig = plt.figure()
ax1 = fig.add_subplot(2,2,1)
ax2 = fig.add_subplot(2,2,2)
ax3 = fig.add_subplot(2,1,3)


plt.setp(ax3.xaxis.get_major_ticks(), pad=20)
plt.show()

But this doesn't have any effect on the final plot.  I've also tried getting
the ticks individually and calling set_pad(20) i.e.:

for tick in ax3.xaxis.get_major_ticks():
    tick.set_pad(20)

But this does't work either. Anyone have an ideas?


-- 
View this message in context: http://old.nabble.com/Different-xtick-pads-for-subplots-within-figure-tp31150430p31150430.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello,

I basically have a Chi-Squared distribution that is dependent on 3
variables.
eg. X2(x, y, z)

What I would like to do is be able to plot the chi-squared + 1 surface in
3-dimensions.
eg. I would like to have the three axes as x, y and z. and then have a
surface (its going to look like a closed blob effectively) that maps the
chi-squared plus one surface.

I have no idea how to do this though. Is it possible? any ideas?
-- 
View this message in context: http://old.nabble.com/3d-Surface-Contour-Plot-tp31143849p31143849.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

For this to work correctly, you need to manually keep two axes in sync
(you can use a callback). Also note that this approach cannot be used
with aspect=1 & adjustable=bbox.

Another way is to use axes_grid1 toolkit.
Here is the modified version of your script w/ axes_grid1.

Regards,

-JJ


import numpy as np
import matplotlib
import matplotlib.colorbar as cb
import matplotlib.pyplot as plt

y = np.reshape(np.arange(0, 1000000, 1), (20000, 50))
test = 'hot'
f1 = plt.figure(1)
f1.patch.set_facecolor('#c0c0c0')

import mpl_toolkits.axes_grid1 as axes_grid1
# use axes_grid1.host_axes
ax1 = axes_grid1.host_axes([0.09, 0.15, 0.82, 0.80])

axc = f1.add_axes([0.09, 0.05, 0.82, 0.05])
im1 = ax1.imshow(y, cmap=test, aspect='auto', origin='lower')
cb.Colorbar(axc, im1, orientation='horizontal')


# use twin() not twinx()
ax2 = ax1.twin()
# make ticklabels on the top invisible
ax2.axis["top"].toggle(ticklabels=False)

fmtr = matplotlib.ticker.FuncFormatter(lambda x,pos: "%.2f"% (x*2,))
ax2.yaxis.set_major_formatter(fmtr)
plt.show()




On Sat, Mar 12, 2011 at 9:01 AM, Thomas Brezinski
<th...@ar...> wrote:
> Jason Stone, on 2011-02-18 14:39,  wrote:
>> Good afternoon all,
>> One last matplotlib question for the group for today.  On one of my GUI
>> plots, I'm calling imshow on an array of data (to display it in the same
>> way
>> MATLAB's imagesc command does).  I'd like to add a second y-axis to the
>> right side of the plot that is completely dependent on the values on the
>> primary y-axis.  Essentially, for each y-axis tick point, I'll put the
>> y-axis 'value' into a formula and then put the result on the second
>> y-axis.
>>  I did this in MATLAB by essentially overlaying a second set of axes over
>> the plot, but I haven't found the exact way to do it with matplotlib yet.
>>  I've seen a few examples online, but they all use the second overlaid
>> plot
>> to actually plot new data - I wouldn't be doing this.
>> Would I need to use the twinx (or twiny) function?
>> Are there examples of this on the web that I haven't found that somebody
>> could point me towards?
>
> Hi Jason,
>
> here's an example that does what you want, using e^x as the
> formula, change the paramter to fmtr to suit your needs:
>
> ax = plt.subplot(1,1,1)
> ax.plot(np.sin(np.linspace(0,np.pi)))
> ax2 = ax.twinx()
> ax2._sharey = ax # share both x and y
> fmtr = mpl.ticker.FuncFormatter(lambda x,pos: "%.2f"%np.exp(x))
> ax2.yaxis.set_major_formatter(fmtr)
> plt.draw()
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
> Paul,
> I am currently doing something very similar and was hoping I could ask for a
> little clarification. I want to have two y axes where the ticks are in the
> same locations and the 2nd y-axis labels are just twice the 1st y-axis
> labels.  When I implement your example, I don't quite understand how to
> ensure the ticks are at the same locations. Also, when the data changes to a
> new image, the 1st y-axis updates but the 2nd y-axis does not. Is there a
> convenient way to force both to update each time, or does the figure need to
> be cleared and essentially built from scratch each time.
>
> for example, with the following code:
>
> import numpy as np
> import matplotlib
> import matplotlib.colorbar as cb
> import matplotlib.pyplot as plt
>
> y = np.reshape(np.arange(0, 1000000, 1), (20000, 50))
> test = 'hot'
> f1 = plt.figure(1)
> f1.patch.set_facecolor('#c0c0c0')
> ax1 = f1.add_axes([0.09, 0.15, 0.82, 0.80])
> axc = f1.add_axes([0.09, 0.05, 0.82, 0.05])
> im1 = ax1.imshow(y, cmap=test, aspect='auto', origin='lower')
> cb.Colorbar(axc, im1, orientation='horizontal')
> ax2 = ax1.twinx()
> ax2._sharey = ax1 # share both x and y
> fmtr = matplotlib.ticker.FuncFormatter(lambda x,pos: "%.2f"%np.exp(x))
> ax2.yaxis.set_major_formatter(fmtr)
> plt.show()
>
> The ticks on the right are obviously at different locations compared to the
> left ticks. Also, if imshow was to be called a new array of data, the ticks
> on the right would remain the same. So is there an easy way to force the
> locations to be the same, and is there an easy way force the right y-axis to
> update each time? Thank you very much for your time and help.
>
> -Thomas
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1kEfIACgkQe+cmRQ8+KPe0vACfSMtFJ9KSRwqU34j6QevaSZqD
> qM0An2WHMyKisrwDIyKaCcuygrsWvZbX
> =OIU1
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

I would like to construct a 3d plot consisting of several 2d quiver plots on
orthogonal, intersecting planes. Is this possible with matplotlib? In matlab
I do it by construct several 2d graph and then reorienting them in the 3d
space using the 'rotate' function. E.g. 

xaxis = [1 0 0];
h = quiver('v6', z, y, w, v, 'k');
rotate(h, xaxis, 90, [0 0 0]);

This produces a 2d quiver plot of [v,w](y,z) oriented along the y,z axes of
the 3d space, and then I do the same for x,y and x,z quiver plots.

Any ideas for matplotib 3d? Thanks!

John Gibson
-- 
View this message in context: http://old.nabble.com/orienting-2d-plots-in-3d-tp31140854p31140854.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks much for the reply!
I'll try your advice as soon as I can.

BTW, I don't think this is a Solaris-related problem.
If you look at the pointers in my original post, the same error can
happen on other arch (I confess it can be for other reasons though).

-n

On Sun, Mar 13, 2011 at 1:03 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> Nicolas SCHEFFER <sch...@gm...> writes:
>
>> I didn't get much reply on this issue, so I'm just trying to resurrect
>> the question.
>
> Probably not many devs using Solaris, so no-one has been able to
> reproduce this.
>
>>> #12 0xfffffd7ff4a22fd8 in py_to_agg_transformation_matrix
>>> (obj=0x774380, errors=<value optimized out>) at
>>> src/agg_py_transforms.cpp:22
>>> #13 0xfffffd7ff4a32e7c in _path_module::update_path_extents
>>> (this=<value optimized out>, args=...) at src/path.cpp:380
>
> So it's in transforms-related code, but we can't see the locals. First
> I'd try to recompile without optimizations and (hoping it still crashes)
> inspect the local variables in these frames in gdb. Or maybe make the
> functions print out their arguments and any other relevant locals.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Pål Gunnar Ellingsen <pa...@gm...> writes:

> This is very strange I agree. I checked the pdftex.map file and it has
> changed due to me upgrading texlive 2011 during a normal fedora update some
> days ago. I've checked the log for the update, and the update contained a
> new updmap.cfg (which is the script for generating pdftex.map), which
> explains the difference in pdftex.map, though it does not help with solving
> the problem.

So it might be caused by updmap configuration. Are you able to compile
TeX source files that contain text in cmr12 using pdftex? E.g., put

    \documentclass[12pt]{article}
    \begin{document}
    foo bar
    \end{document}

in foo.tex and try pdflatex foo.tex. If you run into errors, or if the
output file has ugly bitmap Type-3 fonts like TeX-produced pdf files
used to have in the 1990s, it's clearly a bug in your TeX installation.
If not, it's more a problem in dviread's hijacking of pdftex.map for its
own purposes.

(Oh, I see that your problem is already fixed, but maybe future
searchers will benefit from this suggestion.)

> http://www.linux.cz/pipermail/texlive/2011-March/000105.html(removing
> texlive-amsfonts (without dependencies) and installing it again)
> I tried the solution used there, and it worked, meaning that pdftex.map now
> contains cmr12 and my test.py file runs properly and gives me a nice pdf
> file.

A simpler fix might have been "sudo updmap-sys --enable MixedMap=cm.map".

> So again sorry for messing this up. I would like to thank you very much for
> your help.

No problem, and good that you got it sorted out!

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

Nicolas SCHEFFER <sch...@gm...> writes:

> I didn't get much reply on this issue, so I'm just trying to resurrect
> the question.

Probably not many devs using Solaris, so no-one has been able to
reproduce this.

>> #12 0xfffffd7ff4a22fd8 in py_to_agg_transformation_matrix
>> (obj=0x774380, errors=<value optimized out>) at
>> src/agg_py_transforms.cpp:22
>> #13 0xfffffd7ff4a32e7c in _path_module::update_path_extents
>> (this=<value optimized out>, args=...) at src/path.cpp:380

So it's in transforms-related code, but we can't see the locals. First
I'd try to recompile without optimizations and (hoping it still crashes)
inspect the local variables in these frames in gdb. Or maybe make the
functions print out their arguments and any other relevant locals.

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

Hi,
I didn't get much reply on this issue, so I'm just trying to resurrect
the question.
If there's no easy answer, could someone help me by giving me a
pointer, a method to resolve the problem, or any other quick
advice...?

Thanks much!


On Thu, Mar 10, 2011 at 12:29 AM, Nicolas SCHEFFER
<sch...@gm...> wrote:
> Hi all,
> I am stuck on matplotlib generating a segfault when invoking 'plot'.
> I've ben trying to solve this problem for a while now but no luck.
> I've seen many duplicates of this problem on the web, some with
> solutions, some without. The solution must be something more generic
> that I'm missing.
>
> Here are some of these pointers to the same problem that I have (the
> backtrace, that I pasted further below, has the same properties)
> http://old.nabble.com/101-Point-Segmentation-Fault-td27552745.html
> http://old.nabble.com/weird-error-with-gcc-4.4,-gomp,-cython,-and-matplotlib-td27351399.html
> http://bugs.gentoo.org/show_bug.cgi?id=338513
>
> So here's my specific setup and backtrace. I hope I can find some help!
> I'm using the 'agg' backend that's it, and the build and install dir
> were cleaned up.
>
> Thanks so much!
>
> ===
> Solaris10, 64bits, Python 2.7, numpy 1.5.1, gcc 4.4.1 #all compiled from source
>
> backtrace:
>
> gdb python
> (gdb) run -c 'import pylab;pylab.clf(); pylab.plot([4])'
> Starting program: python -c 'import pylab;pylab.clf(); pylab.plot([4])'
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
> terminate called after throwing an instance of 'std::exception'
> terminate called recursively
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 1 (LWP 1)]
> 0xfffffd7fff0ae88a in _lwp_kill () from /lib/64/libc.so.1
>
>
> #0  0xfffffd7fff0ae88a in _lwp_kill () from /lib/64/libc.so.1
> #1  0xfffffd7fff0a98b3 in thr_kill () from /lib/64/libc.so.1
> #2  0xfffffd7fff0577e9 in raise () from /lib/64/libc.so.1
> #3  0xfffffd7fff03a7d0 in abort () from /lib/64/libc.so.1
> #4  0xfffffd7ff46d1a56 in __gnu_cxx::__verbose_terminate_handler () at
> ../../../../../libstdc++-v3/libsupc++/vterminate.cc:48
> #5  0xfffffd7ff46cef6a in __cxxabiv1::__terminate (handler=0x1) at
> ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
> #6  0xfffffd7ff46cefb3 in std::terminate () at
> ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
> #7  0xfffffd7ff46cf03e in __cxxabiv1::__cxa_rethrow () at
> ../../../../../libstdc++-v3/libsupc++/eh_throw.cc:116
> #8  0xfffffd7ff46d1af6 in __gnu_cxx::__verbose_terminate_handler () at
> ../../../../../libstdc++-v3/libsupc++/vterminate.cc:78
> #9  0xfffffd7ff46cef6a in __cxxabiv1::__terminate (handler=0x1) at
> ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
> #10 0xfffffd7ff46cefb3 in std::terminate () at
> ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
> #11 0xfffffd7ff46cf0b6 in __cxxabiv1::__cxa_throw (obj=<value
> optimized out>, tinfo=<value optimized out>, dest=<value optimized
> out>)
>    at ../../../../../libstdc++-v3/libsupc++/eh_throw.cc:83
> #12 0xfffffd7ff4a22fd8 in py_to_agg_transformation_matrix
> (obj=0x774380, errors=<value optimized out>) at
> src/agg_py_transforms.cpp:22
> #13 0xfffffd7ff4a32e7c in _path_module::update_path_extents
> (this=<value optimized out>, args=...) at src/path.cpp:380
> #14 0xfffffd7ff4a34d90 in
> Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
> optimized out>,
>    method_def=<value optimized out>, args=...) at
> ./CXX/Python2/ExtensionModule.hxx:184
> #15 0xfffffd7ff4a209b7 in Py::method_varargs_call_handler
> (_self_and_name_tuple=<value optimized out>, _args=<value optimized
> out>)
>    at CXX/Python2/cxx_extensions.cxx:1714
> #16 0x00000000004a6071 in call_function (f=0x2024770, throwflag=<value
> optimized out>)
>    at /usr/local/src/lang/Python-2.7.1/Python/ceval.c:4012
> #17 PyEval_EvalFrameEx (f=0x2024770, throwflag=<value optimized out>)
> at /usr/local/src/lang/Python-2.7.1/Python/ceval.c:2665
> #18 0x00000000004a79c1 in PyEval_EvalCodeEx (co=0x124e230,
> globals=<value optimized out>, locals=<value optimized out>,
> args=0x2024910,
>    argcount=<value optimized out>, kws=0x3, kwcount=2,
> defs=0x155c888, defcount=3, closure=0x0)
>

On Sunday, March 13, 2011, onet <on...@dd...> wrote:
> On Fri, 2011-03-11 at 17:08 -1000, Eric Firing wrote:
>> On 03/11/2011 02:54 PM, onet wrote:
>> > Using matplotlib I try to plot satellite observations, which consists of
>> > roughly one million patches that are not gridded regularly.
>> > I first collect the vertices (corner points of the observations) and
>> > colors and then use PolyCollection and ax.add_collection to add these
>> > patches to the figure.
>> >
>> > On my 64bit Linux machine:
>> > # 1M patches will use>  4Gb of memory
>> >
>> > My question: how can I plot more efficiently and use less memory?
>>
>> If your data are on a quadrilateral mesh, as in your example, (or can be
>> approximately mapped onto such a mesh) then pcolormesh should be very
>> much more efficient both in time and in memory than making a PolyCollection.
>
> The data I want to plot is not as regular as in the example (this was
> just to generate lots of non-overlaping patches) but it has different
> shapes along the orbit of the satellite when projected on the map.
> Almost square at the equator and rotated near the poles. See example
> link below from a plot in IDL.
>
> http://temis.nl/o3msaf/vaac/gome2/vaac/daily/images/2011/S-O3M_GOME_NAR_02_M02_20110312000254Z_20110313000254Z_N_O_20110313024518Z.AAI_Global.Unfiltered.png
>
> But I think my satellite data along an orbit is probably piecewise
> regular enough try the pcolormesh approach.
>
> So thanks for the suggestion!
>
> Best regards,
>
>         Olaf.
>

It might be regular with respect to a particular projection.  Have you
considered checking out Basemap?

Ben Root

Okay, I just confirmed that using a gs distiller greatly increases the
file size with gs 9.0.
I have no idea what's going on and I hope that someone more
knowledgeable than me steps in.
Meanwhile, using the "ps2write" device with gs seems to solve the
issue (but I'm not sure of its consequences).
So, can you test if the workaround works?

In lib/matplotlib/backends/backend_ps.py, search for the following
line in the "gs_distill" function,

    command = '%s -dBATCH -dNOPAUSE -r%d -sDEVICE=pswrite %s -sOutputFile="%s" \

and replace "pswrite" with "ps2write".

Regards,

-JJ




On Sun, Mar 13, 2011 at 1:45 AM, Thomas Robitaille
<tho...@gm...> wrote:
> Hi Jae-Joon,
>
> Ok, that makes sense - I tried upgrading to 9.0.1 and it looks like there is still an issue:
>
> 6204    test_1.eps
> 34104   test_2.eps
>
> Cheers,
> Tom
>
> On Mar 12, 2011, at 11:38 AM, Jae-Joon Lee wrote:
>
>> Note that, even with usetex=False,  you have a large ps file when
>> distiller is used .
>> When usetex=True, the distiller is always used (if distiller=None,
>> ghostscript is used).
>> Therefore, my guess is that the large file size is results of
>> distilling using the ghostscript.
>> I wonder if this is an issue of gs 9.0 version.
>> In my installation (gs 8.xx), the original ps file is about 6 M (both
>> usetex=True and False), and when they are distilled, their size is
>> reduced down to 4 M.
>>
>> I'll try to test gs 9.0 when I get a chance.
>> Meanwhile, can you try to upgrade to gs 9.01 and see if it changes anything?
>>
>> Regards,
>>
>> -JJ
>>
>>
>>
>> On Sat, Mar 12, 2011 at 2:46 AM, Thomas Robitaille
>> <tho...@gm...> wrote:
>>> Hi Jae-Joon,
>>>
>>> I tried inserting:
>>>
>>> mpl.rc('ps', usedistiller=None)
>>>
>>> after importing matplotlib, and I get:
>>>
>>> $ du -sk *.eps
>>> 6204    test_1.eps
>>> 34104   test_2.eps
>>>
>>> using 'ghostscript' I get:
>>>
>>> $ du -sk *.eps
>>> 34096   test_1.eps
>>> 34104   test_2.eps
>>>
>>> and using 'xpdf' raises an exception:
>>>
>>>  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/backends/backend_ps.py", line 1091, in _print_figure
>>>    xpdf_distill(tmpfile, isEPSF, ptype=papertype, bbox=bbox)
>>>  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/backends/backend_ps.py", line 1421, in xpdf_distill
>>>    image.\nHere is the full report generated by pdftops: \n\n' + fh.read())
>>> RuntimeError: pdftops was not able to process your image.
>>> Here is the full report generated by pdftops:
>>>
>>> I don't have a matplotlibrc file, and I am using:
>>>
>>> Ghostscript: GPL Ghostscript  9.00 (2010-09-14)
>>> LaTeX: Version 3.1415926-1.40.10 (TeX Live 2009)
>>>
>>> and I'm using the latest head from github for matplotlib.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Mar 8, 2011, at 7:31 AM, Jae-Joon Lee wrote:
>>>
>>>> With current master at git repo, I cannot reproduce this.
>>>> Both test_1.eps and test_2.eps are ~4M in size.
>>>>
>>>> Can you check if the file size varies significantly with rc parameters
>>>> ps.usedistiller?
>>>> I'm not sure how text setting can affect the images.
>>>>
>>>> Regards,
>>>>
>>>> -JJ
>>>>
>>>>
>>>>
>>>> On Tue, Mar 1, 2011 at 7:23 AM, Thomas Robitaille
>>>> <tho...@gm...> wrote:
>>>>> Hi,
>>>>>
>>>>> In the following example:
>>>>>
>>>>> ---
>>>>>
>>>>> import numpy as np
>>>>>
>>>>> import matplotlib as mpl
>>>>> mpl.use('Agg')
>>>>> import matplotlib.pyplot as plt
>>>>>
>>>>> fig = plt.figure()
>>>>> ax = fig.add_subplot(1, 1, 1)
>>>>> ax.imshow(np.random.random((1024, 1024)), interpolation='nearest')
>>>>> fig.savefig('test_1.eps')
>>>>>
>>>>> mpl.rc('text', usetex=True)
>>>>>
>>>>> fig = plt.figure()
>>>>> ax = fig.add_subplot(1, 1, 1)
>>>>> ax.imshow(np.random.random((1024, 1024)), interpolation='nearest')
>>>>> fig.savefig('test_2.eps')
>>>>>
>>>>> ---
>>>>>
>>>>> the file test_2.eps is almost 6 times larger than test_1.eps, and takes much longer to draw. It looks like in the first case, the image is rendered as a bitmap (the way it should be), whereas in the second case each pixel is drawn individually as a polygon. Is this a bug?
>>>>>
>>>>> I am using r8988 of matplotlib.
>>>>>
>>>>> Thanks for any help!
>>>>>
>>>>> Thomas
>>>>> ------------------------------------------------------------------------------
>>>>> Free Software Download: Index, Search & Analyze Logs and other IT data in
>>>>> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
>>>>> generated by your applications, servers and devices whether physical, virtual
>>>>> or in the cloud. Deliver compliance at lower cost and gain new business
>>>>> insights. http://p.sf.net/sfu/splunk-dev2dev
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>
>>>
>
>

On Fri, 2011-03-11 at 17:08 -1000, Eric Firing wrote:
> On 03/11/2011 02:54 PM, onet wrote:
> > Using matplotlib I try to plot satellite observations, which consists of
> > roughly one million patches that are not gridded regularly.
> > I first collect the vertices (corner points of the observations) and
> > colors and then use PolyCollection and ax.add_collection to add these
> > patches to the figure.
> >
> > On my 64bit Linux machine:
> > # 1M patches will use>  4Gb of memory
> >
> > My question: how can I plot more efficiently and use less memory?
> 
> If your data are on a quadrilateral mesh, as in your example, (or can be 
> approximately mapped onto such a mesh) then pcolormesh should be very 
> much more efficient both in time and in memory than making a PolyCollection.

The data I want to plot is not as regular as in the example (this was
just to generate lots of non-overlaping patches) but it has different
shapes along the orbit of the satellite when projected on the map.
Almost square at the equator and rotated near the poles. See example
link below from a plot in IDL. 

http://temis.nl/o3msaf/vaac/gome2/vaac/daily/images/2011/S-O3M_GOME_NAR_02_M02_20110312000254Z_20110313000254Z_N_O_20110313024518Z.AAI_Global.Unfiltered.png

But I think my satellite data along an orbit is probably piecewise
regular enough try the pcolormesh approach. 

So thanks for the suggestion!

Best regards,

	Olaf.

Hi

This is very strange I agree. I checked the pdftex.map file and it has
changed due to me upgrading texlive 2011 during a normal fedora update some
days ago. I've checked the log for the update, and the update contained a
new updmap.cfg (which is the script for generating pdftex.map), which
explains the difference in pdftex.map, though it does not help with solving
the problem.

>From now on I'll check the update list closer, I'm sorry for the
inconvenience on your part.The current pdftex.map file does not have the
cmr12 font (or any other cmr fonts). Which means that it explains the lack
of the font, but doesn't help me, so I continued looking for errors.

There was a new version of TexLive out, I updated, but it did not fix the
problem (pdftex.map still lacked cmr fonts).

I checked the Fedora TExlive maling list and found that there were similar
problems there:
http://www.linux.cz/pipermail/texlive/2011-March/000105.html(removing
texlive-amsfonts (without dependencies) and installing it again)
I tried the solution used there, and it worked, meaning that pdftex.map now
contains cmr12 and my test.py file runs properly and gives me a nice pdf
file.

So again sorry for messing this up. I would like to thank you very much for
your help.

If CC-d this e-mail to the  TexLive mailing list, in case others have the
same problem, and I also figured that this problem with the pdftex.map file
should be fixed.

Regards

Pål



On 12 March 2011 22:24, Jouni K. Seppänen <jk...@ik...> wrote:

> Jouni K. Seppänen <jk...@ik...> writes:
>
> > Set verbose to debug-annoying and catch the output in a file; there will
> > be lots of it, so please email it to me off-list.
>
> Got it, thanks. Unfortunately I have no idea what's going on. The debug
> information indicates that the PsfontsMap._register function (which only
> gets called from within the loop in PsfontsMap._parse) is called with
> pdftex.map lines out of order, and lacking some of the lines.
>
> The pdftex.map file you sent me starts with some comments followed by
> these entries:
>
>    ASCII ASCII <ASCII.pfb
>    Acorn AcornInitials <Acorn.pfb
>    AlphaDia ChessAlphaDiagram <AlphaDia.pfb
>    AmiciLogo AmiciLogo <AmiciLogo.pfb
>
> The log messages, on the other hand, start like this:
>
>    PsfontsMap: register ['Acorn', 'AcornInitials', '<Acorn.pfb']
>    PsfontsMap: register ['aealbattar', 'ae_AlBattar',
> 'ArabeyesArabicEncoding ReEncodeFont', '<ararabeyes.enc',
> '<ae_albattar.pfb']
>    PsfontsMap: register ['aealmateen', 'ae_AlMateen',
> 'ArabeyesArabicEncoding ReEncodeFont', '<ararabeyes.enc',
> '<ae_almateen.pfb']
>
> Here's a small table. The first column is just line numbers within that
> part of the debug log, the second is the number of the entry in
> pdftex.map referenced, the third is the first word of that entry:
>
>    1 2 Acorn
>    2 279 aealbattar
>    3 280 aealmateen
>    4 281 aealmohanadb
>    5 282 aealmohanadbolditalic
>    6 278 ae_almohanad_xxbold
>    7 283 aealmothnna
>    8 284 aealyermook
>    9 285 aearab
>
> So it first gets entry #2 (Acorn) from the file, then jumps to entry
> #279 (aealbattar) and starts going forward from there, except #278 gets
> between #282 and #283. It goes on like this for a while, then:
>
>    32 308 aetarablus
>    33 309 aetholoth
>    34 3 AlphaDia
>    35 4 AmiciLogo
>    36 5 AmiciLogoBold
>    37 6 AmiciLogoBoldRslant
>    38 7 AmiciLogoBoldSlant
>    39 8 AmiciLogoRslant
>    40 9 AmiciLogoSlant
>    41 310 andlso
>    42 10 AnnSton
>    43 311 aram10
>
> So after #309 it jumps back to #3 for a while, etc., and the critical
> font cmr12 is skipped altogether.
>
> Hmm. The ordering is almost consistent with sorting the font names
> case-insensitively, but that wouldn't explain the missing fonts.
>
> Could you double-check that you sent me the correct pdftex.map file?
> Run on the system where you have this problem e.g. the following
> commands:
>
>    kpsewhich pdftex.map
>    head `kpsewhich pdftex.map`
>
> and check that ASCII, Acorn, and AlphaDia are the first three
> non-comment entries.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hey,

I have a family of curves to plot. They all look somewhat similar and
hardly cross, but a parameter is changed, so adding labels to them in a
contour plot fashion would be cool. I will just do this by hand now
likely, but as clabels works nice I was wondering if this can be used or
abused for usual lines too?

Regards,

Sebastian

Jouni K. Seppänen <jk...@ik...> writes:

> Set verbose to debug-annoying and catch the output in a file; there will
> be lots of it, so please email it to me off-list.

Got it, thanks. Unfortunately I have no idea what's going on. The debug
information indicates that the PsfontsMap._register function (which only
gets called from within the loop in PsfontsMap._parse) is called with
pdftex.map lines out of order, and lacking some of the lines.

The pdftex.map file you sent me starts with some comments followed by
these entries:

    ASCII ASCII <ASCII.pfb
    Acorn AcornInitials <Acorn.pfb
    AlphaDia ChessAlphaDiagram <AlphaDia.pfb
    AmiciLogo AmiciLogo <AmiciLogo.pfb

The log messages, on the other hand, start like this:

    PsfontsMap: register ['Acorn', 'AcornInitials', '<Acorn.pfb']
    PsfontsMap: register ['aealbattar', 'ae_AlBattar', 'ArabeyesArabicEncoding ReEncodeFont', '<ararabeyes.enc', '<ae_albattar.pfb']
    PsfontsMap: register ['aealmateen', 'ae_AlMateen', 'ArabeyesArabicEncoding ReEncodeFont', '<ararabeyes.enc', '<ae_almateen.pfb']

Here's a small table. The first column is just line numbers within that
part of the debug log, the second is the number of the entry in
pdftex.map referenced, the third is the first word of that entry:

    1 2 Acorn
    2 279 aealbattar
    3 280 aealmateen
    4 281 aealmohanadb
    5 282 aealmohanadbolditalic
    6 278 ae_almohanad_xxbold
    7 283 aealmothnna
    8 284 aealyermook
    9 285 aearab

So it first gets entry #2 (Acorn) from the file, then jumps to entry
#279 (aealbattar) and starts going forward from there, except #278 gets
between #282 and #283. It goes on like this for a while, then:

    32 308 aetarablus
    33 309 aetholoth
    34 3 AlphaDia
    35 4 AmiciLogo
    36 5 AmiciLogoBold
    37 6 AmiciLogoBoldRslant
    38 7 AmiciLogoBoldSlant
    39 8 AmiciLogoRslant
    40 9 AmiciLogoSlant
    41 310 andlso
    42 10 AnnSton
    43 311 aram10

So after #309 it jumps back to #3 for a while, etc., and the critical
font cmr12 is skipped altogether.

Hmm. The ordering is almost consistent with sorting the font names
case-insensitively, but that wouldn't explain the missing fonts.

Could you double-check that you sent me the correct pdftex.map file?
Run on the system where you have this problem e.g. the following
commands:

    kpsewhich pdftex.map
    head `kpsewhich pdftex.map`

and check that ASCII, Acorn, and AlphaDia are the first three
non-comment entries.

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