matplotlib-users Mailing List for matplotlib

2010年2月27日 David Goldsmith <d_l...@ya...>:
> ax.imshow(image[0:ny/2+1, 0:nx/2+1]) # upper left corner of image
>   ax.imshow(argW[ny/2+1:-1, 0:nx/2+1]) # lower left corner of image
>   ax.imshow(argW[0:ny/2+1, nx/2+1:-1]) # upper right corner of image
>   ax.imshow(argW[ny/2+1:-1, nx/2+1:-1]) # lower right corner of image
Some tiny improvement:
ax.imshow(argW[:ny/2+1, :nx/2+1])
ax.imshow(argW[ny/2+1:, :nx/2+1])
ax.imshow(argW[:ny/2+1, nx/2+1:])
ax.imshow(argW[ny/2+1:, nx/2+1:])
The main advantage is that you do not cut off the last pixel
row/column by indicing [:-1], which will run until the last index
*before* the index -1.
>>> a = numpy.asarray([1, 2, 3])
>>> a[:-1]
array([1, 2])
Friedrich

On Mon, Mar 1, 2010 at 8:36 AM, Michael Droettboom <md...@st...> wrote:
> Alan G Isaac wrote:
> >> Gökhan Sever wrote:
> >>
> >>> For the second idea you mean something as generic as plotting such
> >>> markers?
> >>> plt.plot(range(10), linestyle='None', marker=u'※(注記) ')
> >>>
> >
> >
> > On 3/1/2010 8:33 AM, Michael Droettboom wrote:
> >
> >> Yes -- but it can't be quite this simple, since there is already a set
> >> of strings that have specific meanings for markers, and we wouldn't
> want
> >> to change that behavior. In order to use an arbitrary character or
> >> string, we'd need additional syntax to indicate that's what you want to
> >> do.
> >>
> >
> >
> > Perhaps naively, I do not see why.
> > A small number of strings have predefined meanings.
> > Just keep documenting that and then test if the
> > provided string is in this set.
> > Otherwise, use the provided string.
> > This seems very nice.
> >
> > If that is too implicit, then adding a markerstr keyword argument
> > seems the right way to go. It would override the marker argument,
> > and any string could be used, getting rid of the above problem.
> >
> > Cheers,
> > Alan Isaac
> > (just a user)
> >
> What if you want to use the letter 'o' as a marker? That to me seems
> like a potential source of confusion, as well as a little bit limiting.
> What would the escaping syntax be to use the letter 'o'?
>
> As you suggest, adding an additional kwarg is also a way forward. In
> that case, though, I would suggest that providing both a marker and
> markerstr argument should raise an exception. Having implicit
> overriding rules can often lead to confusion.
>
> One downside of the additional kwarg is that you occasionally see code
> like this:
>
> markers = ['o', '.', 'h', 'x']
> for data, marker in zip(datasets, markers):
> plot(data, marker=marker)
>
> If one wanted to mix built-in with non-built-in markers that idiom would
> become much more complex. That's why I proposed sticking to a purely
> string representation -- I'm just not sure of the best or most obvious one.
>
To me it seems like having only one keyword "marker" is easier for the sake
of simplicity as you have already demonstrated with an example. (Having one
keyword to handle all special markers, unicode symbols and strings.) However
probably this will need more coding to handle all the cases properly.
>
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Gökhan

On Mon, Mar 1, 2010 at 2:27 PM, Matthew MacLeod
<ma...@ee...>wrote:
> Dear matplolib users,
>
>
> I am wondering if anyone knows how to increase the tick thickness, that is
> the tick linewidth? Mine are too thin.
>
> Thanks Goekhan and JJ for the help previously on how to increase the tick
> size, to fix the
>
> xtick.major.size
>
> in the matplotlib rc. That did make my ticks longer, but I still don't
> know how to make them 'fatter'.
>
>
> Thanks,
> Matthew
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
Hi Matthew,
JJ's suggestion should work to make the ticks bolder:
http://matplotlib.sourceforge.net/users/artists.html#axis-containers (See
the lines at the very bottom)
In your code you should
import matplotlib.pyplot as plt
plt.plot(range(10)
ax = plt.gca() #for each axis or whichever axis you want you should
for line in ax.xaxis.get_ticklines():
 line.set_markeredgewidth(3)
This makes the x-ticks substantially visible.
-- 
Gökhan

Dear matplolib users,
I am wondering if anyone knows how to increase the tick thickness, that is 
the tick linewidth? Mine are too thin.
Thanks Goekhan and JJ for the help previously on how to increase the tick 
size, to fix the
xtick.major.size
in the matplotlib rc. That did make my ticks longer, but I still don't 
know how to make them 'fatter'.
Thanks,
Matthew

I use Tbird, and I think any jpg file I send is encoded in an acceptable 
format for e-mail delivery. Aside from using attachments here, I 
recently noticed another Python list only allows 40K.
On 3/1/2010 7:58 AM, John Hunter wrote:
> On Mon, Mar 1, 2010 at 9:45 AM, Wayne Watson
> <sie...@sb...> wrote:
> 
>> See Subject. Is it 40K?
>> 
> The max size of the message body is 200K. If you are sending
> attachments, they will be mime encoded, so they encoding may be larger
> than the file size, and the limit applies to the encoded size. I am
> the list moderator and will often approve messages over the limit if
>
> * they are not too far over the limit
>
> * they are topical and relevant
>
> I usually moderate the messages once a day.
>
> Many people use free drop services for larger attachments, eg http://drop.io
>
> JDH
>
> 
-- 
 Wayne Watson (Watson Adventures, Prop., Nevada City, CA)
 (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
 Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet
 Stop the illegal killing of dolphins and porpoises.
 <http://www.takepart.com/thecove>
 Wrest the control of the world's fisheries from Japan.
 Web Page:<www.speckledwithstars.net/>

On Mon, Mar 1, 2010 at 9:45 AM, Wayne Watson
<sie...@sb...> wrote:
> See Subject. Is it 40K?
The max size of the message body is 200K. If you are sending
attachments, they will be mime encoded, so they encoding may be larger
than the file size, and the limit applies to the encoded size. I am
the list moderator and will often approve messages over the limit if
 * they are not too far over the limit
 * they are topical and relevant
I usually moderate the messages once a day.
Many people use free drop services for larger attachments, eg http://drop.io
JDH

See Subject. Is it 40K?
-- 
 Wayne Watson (Watson Adventures, Prop., Nevada City, CA)
 (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
 Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet
 Stop the illegal killing of dolphins and porpoises.
 <http://www.takepart.com/thecove>
 Wrest the control of the world's fisheries from Japan.
 Web Page:<www.speckledwithstars.net/>

On 3/1/2010 9:36 AM, Michael Droettboom wrote:
> What if you want to use the letter 'o' as a marker? That to me seems 
like a potential source of confusion, as well as a little bit limiting. 
What would the escaping syntax be to use the letter 'o'?
Maybe:
allow only unicode strings as string markers
and test with `is`::
 >>> 'o' is 'o'
 True
 >>> 'o' is u'o'
 False
Alan Isaac

Alan G Isaac wrote:
>> Gökhan Sever wrote:
>> 
>>> For the second idea you mean something as generic as plotting such
>>> markers?
>>> plt.plot(range(10), linestyle='None', marker=u'※(注記) ')
>>> 
>
>
> On 3/1/2010 8:33 AM, Michael Droettboom wrote:
> 
>> Yes -- but it can't be quite this simple, since there is already a set
>> of strings that have specific meanings for markers, and we wouldn't want
>> to change that behavior. In order to use an arbitrary character or
>> string, we'd need additional syntax to indicate that's what you want to
>> do.
>> 
>
>
> Perhaps naively, I do not see why.
> A small number of strings have predefined meanings.
> Just keep documenting that and then test if the
> provided string is in this set.
> Otherwise, use the provided string.
> This seems very nice.
>
> If that is too implicit, then adding a markerstr keyword argument
> seems the right way to go. It would override the marker argument,
> and any string could be used, getting rid of the above problem.
>
> Cheers,
> Alan Isaac
> (just a user)
> 
What if you want to use the letter 'o' as a marker? That to me seems 
like a potential source of confusion, as well as a little bit limiting. 
What would the escaping syntax be to use the letter 'o'?
As you suggest, adding an additional kwarg is also a way forward. In 
that case, though, I would suggest that providing both a marker and 
markerstr argument should raise an exception. Having implicit 
overriding rules can often lead to confusion.
One downside of the additional kwarg is that you occasionally see code 
like this:
markers = ['o', '.', 'h', 'x']
for data, marker in zip(datasets, markers):
 plot(data, marker=marker)
If one wanted to mix built-in with non-built-in markers that idiom would 
become much more complex. That's why I proposed sticking to a purely 
string representation -- I'm just not sure of the best or most obvious one.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

> Gökhan Sever wrote:
> > For the second idea you mean something as generic as plotting such
> > markers?
> > plt.plot(range(10), linestyle='None', marker=u'※(注記) ')
On 3/1/2010 8:33 AM, Michael Droettboom wrote:
> Yes -- but it can't be quite this simple, since there is already a set
> of strings that have specific meanings for markers, and we wouldn't want
> to change that behavior. In order to use an arbitrary character or
> string, we'd need additional syntax to indicate that's what you want to
> do.
Perhaps naively, I do not see why.
A small number of strings have predefined meanings.
Just keep documenting that and then test if the
provided string is in this set.
Otherwise, use the provided string.
This seems very nice.
If that is too implicit, then adding a markerstr keyword argument
seems the right way to go. It would override the marker argument,
and any string could be used, getting rid of the above problem.
Cheers,
Alan Isaac
(just a user)

Gökhan Sever wrote:
> Thanks again. I didn't know it was complete :)
>
> For the second idea you mean something as generic as plotting such 
> markers?
>
> plt.plot(range(10), linestyle='None', marker=u'※(注記) ')
Yes -- but it can't be quite this simple, since there is already a set 
of strings that have specific meanings for markers, and we wouldn't want 
to change that behavior. In order to use an arbitrary character or 
string, we'd need additional syntax to indicate that's what you want to 
do. For example:
plt.plot(range(10), linestyle='None', marker=u'(※(注記))')
But I'm hoping someone can suggest a more obvious way to do it.
Mike
>
>
>
> On Fri, Feb 26, 2010 at 2:56 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> SVN trunk has support for mathtext as symbol markers --
>
> plot(range(10), linestyle='None', marker=r'$\clubsuit$')
>
> We could support arbitrary (non-math) text, too, fairly easily.
> We just need to invent a syntax for it.
>
> Mike
>
> Gökhan Sever wrote:
>
> Thanks Mike. The Greek symbols become visible when I make the
> changes as you suggested. DejaVu Sans has been installed in my
> system (Fedora 12). We might put a note on the documentation
> stating to get wider Unicode coverage people could install
> additional fonts --DejaVu Sans being one of them instead of
> shipping the fonts with matplotlib.
>
> With my working unicode example, now I have three ways to show
> u^-2 on labels. See the code at:
> http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py
>
> Not heavy Latex users like me might find unicode fonts much
> easier to create their labels. Especially using units like #/cm^3.
>
> There are so many nice looking symbols in the DejaVu Sans
> samples at http://dejavu.sf.net/samples/DejaVuSans.pdf
> Is it possible in matplotlib to use those symbols as
> replacement for regular markers while plotting? I recall
> someone was asking about using Latex symbols as markers, but
> not sure about the fate of his question.
>
> Thanks
>
> On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom
> <md...@st... <mailto:md...@st...>
> <mailto:md...@st... <mailto:md...@st...>>> wrote:
>
> Thanks for the reminder. Sorry this fell through the cracks.
>
> The reason this worked for me and not for you is that I had set
> (and later forgotten) font.sans-serif to the following:
>
> font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida
> Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde,
> sans-serif
>
> DejaVu Sans is the successor to Vera Sans that includes much
> larger Unicode coverage, including the Greek characters here.
> Vera Sans (at least the version shipped with matplotlib)
> does not
> include these characters.
>
> It's an open question whether we want to ship the larger DejaVu
> fonts with matplotlib (and annoy the distro packagers even
> further
> who already dislike some of matplotlib's redundancy). A less
> disruptive change may be to change the rc defaults to put
> DejaVu
> in front of Vera, even though we don't ship DejaVu. This will
> help the majority of Linux users on modern distros (where
> DejaVu
> is almost always installed by default, I suspect), and
> still have
> our own Vera as a fallback (albeit with a more limited
> character
> set). Especially since DejaVu and Vera are basically the same
> font, and substituting one for the other would not change the
> appearance of plots, I think this a reasonably safe thing
> to do --
> but I'd appreciate feedback in case I haven't thought
> through all
> the issues.
>
> Mike
>
> Gökhan Sever wrote:
>
>
>
> On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom
> <md...@st... <mailto:md...@st...>
> <mailto:md...@st... <mailto:md...@st...>>
> <mailto:md...@st... <mailto:md...@st...>
> <mailto:md...@st... <mailto:md...@st...>>>> wrote:
>
> On 01/28/2010 08:08 PM, Gökhan Sever wrote:
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
>
> from pylab import *
>
> plot([1]*5)
> xlabel(u'μ = 50')
> ylabel(u'σ = 1.5')
>
> show()
>
> It works for me. Can you provide a screenshot and the
> output from
> matplotlib with "verbose.level : debug-annoying" in your
> matplotlibrc?
>
> Mike
>
>
> Mike,
>
> Attached are the outputs. Which font do you activated
> in your
> matplotlibrc? Currently non-active in mine.
>
>
> -- Gökhan
> 
> ------------------------------------------------------------------------
>
>
> -- Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
>
> -- 
> Gökhan
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
>
> -- 
> Gökhan
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

David Goldsmith wrote:
> --- On Sun, 2/28/10, David Goldsmith <d_l...@ya...> wrote:
>
> 
>>>>>> Question 2) is there some way I can add
>>>>>> 
>>> pieces of the
>>> 
>>>>> array incrementally to
>>>>> 
>>>>>> the image into their proper place,
>>>>>> 
>> i.e.,
>> 
>>> modify the
>>> 
>>>>> following code:
>>>>> 
>>>>>> ax.imshow(image[0:ny/2+1,
>>>>>> 
>> 0:nx/2+1]) #
>> 
>>> upper
>>> 
>>>>> left corner of image
>>>>> 
>>>>>> ax.hold(True)
>>>>>> ax.imshow(argW[ny/2+1:-1,
>>>>>> 
>> 0:nx/2+1]) #
>> 
>>> lower
>>> 
>>>>> left corner of image
>>>>> 
>>>>>> ax.imshow(argW[0:ny/2+1,
>>>>>> 
>> nx/2+1:-1]) #
>> 
>>> upper
>>> 
>>>>> right corner of image
>>>>> 
>>>>>> ax.imshow(argW[ny/2+1:-1,
>>>>>> 
>> nx/2+1:-1])
>> 
>>> # lower
>>> 
>>>>> right corner of image
>>>>>
>>>>> Try the extents keyword argument. It let's
>>>>> 
>> you
>> 
>>> specify the
>>> 
>>>>> corners of
>>>>> the image in data coordinates.
>>>>>
>>>>> Ryan
>>>>> 
>>>> Hi, Ryan, thanks! Can you be a little more
>>>> 
>> specific
>> 
>>> as to how I should try that? I tried:
>>> 
>>>> ax.imshow(argW[0:ny/2+1, 0:nx/2+1], cmap_name,
>>>> 
>>> extent=(0,nx/2,ny/2,0))
>>> 
>>>> ax.hold(True)
>>>> ax.imshow(argW[ny/2+1:-1, 0:nx/2+1], cmap_name,
>>>> 
>>> extent=(0,nx/2,ny,ny/2))
>>> 
>>>> ax.imshow(argW[0:ny/2+1, nx/2+1:-1], cmap_name,
>>>> 
>>> extent=(nx/2,nx,ny/2,0))
>>> 
>>>> ax.imshow(argW[ny/2+1:-1, nx/2+1:-1], cmap_name,
>>>> 
>>> extent=(nx/2,nx,ny,ny/2))
>>> 
>>>> which didn't work (I only got one "corner" - the
>>>> 
>> last
>> 
>>> one, I think - i.e., I think it's still just putting
>>> subsequent images on top of prior ones).
>>>
>>> Based on just a quick look, I'd make sure:
>>>
>>> 1) To set the x and y limits appropriately:
>>>
>>> ax.set_xlim(0, nx)
>>> ax.set_ylim(ny, 0)
>>> 
>> I'll try it out and report back.
>> 
>
> Nope, still only getting the last corner. Let me give a little more of my code:
> 
David: Just add
ax.set_xlim(0,nx)
ax.set_ylim(0,ny)
after you imshow calls. The axes limits are being automatically set to 
match your last invocation of imshow.
-Jeff
> import numpy as N
> from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
> from matplotlib.figure import Figure
>
> w, h, DPI = (8.2, 6.2, 50)
> fig = Figure(figsize=(w, h), 
> dpi=DPI,
> frameon=False)
> ax = fig.add_subplot(1,1,1)
> canvas = FigureCanvas(fig)
>
> nx, xmin, xmax = (int(w*DPI), -0.5, 0.5)
> ny, ymin, ymax = (int(h*DPI), 0.6, 1.2)
> W = N.zeros((ny,nx),N.complex)
>
> ## Generate non-trivial W; unnecessary for code to run, I think
>
> argW = N.angle(W)
>
> ax.set_xlim(0, nx)
> ax.set_ylim(ny, 0)
> ax.imshow(argW[0:ny/2, 0:nx/2], extent=(0, nx/2 - 1, ny/2 - 1, 0))
> ax.hold(True)
> ax.imshow(argW[ny/2:-1, 0:nx/2], extent=(0, nx/2 - 1, ny, ny/2))
> ax.imshow(argW[0:ny/2, nx/2:-1], extent=(nx/2, nx, ny/2 - 1, 0))
> ax.imshow(argW[ny/2:-1, nx/2:-1], extent=(nx/2, nx, ny, ny/2))
> canvas.print_figure(fid, dpi=DPI)
>
> DG
> 

Hi,
Sorry to repost but I'm tearing my hair out with this one....
I'm using the Python(x,y) distribution which comes with matplotlib for
Windows. My OS is Windows XP with all updates and service packs on an
AMD Athlon 2600+ PC with ATI Radeon 9600 graiphics card.
Python will work fine for anything that doesn't import the pylab
component (I can import matplotlib itself no problem as well as numpy
etc) but if I try to import pylab I get:-
"An unhandled exception occured in pythonw.exe [3976]"
I've tied reinstalling Python(x,y) and even reinstalling windows then
Python(x,y) but to no avail. This seems odd to me as 2 other PCs at work
install Python(x,y) and run Pylab fine.
Any suggestions as to what I should check to track down this error?
Thanks
Jon
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4904 (20100301) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

Hi Jae-Joon & All,
On 28 February 2010 03:09, Jae-Joon Lee wrote:
> If I read your correctly,
>
>    for l, b in zip(x, y):
>
>     # And here I work with data coordinates (!)
>
>      dashBox = Bbox.from_bounds(l, b, width+5, height+5)
>      badness = 0
>      for line in lines:
>        if line.intersects_bbox(dashBox):
>          badness += 1
>
> x, y (therefore l, b) in data coordinate.
> width, height?? this seems to be some wx specific coordinate, i have no idea.
> lines (therefore line) in display coordinate.
>
> converting x,y to display coordinate should straight forward. But I'm
> not sure what kind of coordinate width and height has. Is it a method
> of some class derived from matplotlib's Text?? If then, the extent of
> the text can be measured using the get_window_extent method. This
> requires a renderer instance, which should be known if the method is
> called during the drawing time.
>
> Again, post a complete but simple(!) code.
OK, I think I got a complete code. Not super-simple, but simple enough
I believe. After you run it you'll see a bunch of points and lines
with some text. If you left-click inside the axis this will start the
calculations for the "optimal positioning". There are a couple of
problems:
1) The code I have looks only for optimal positioning with respect to
lines in the plot, it doesn't include texts (I don't know how to do
it); You'll see what I mean if you run the code, the "optimally"
positioned texts overlap with other text in the plot, and with
themselves too (i.e., one "optimally" positioned text overlap with
another "optimally" positioned text);
2) The code as it stands it's veeeeery slow. On my (relatively fast)
computer, it takes almost 6 seconds to "optimally" position 14 labels.
In order to run the code, you'll also need the "lines.txt" file, which
contains the main lines coordinates. Sorry about this extra file but I
wanted it to be as close as possible to my use-case.
Thank you in advance for your suggestions.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/

Hello 
I have encountered memory leak when using pylab.figure(), pylab.show(),
pylab.close(). I expected pylab.close() to flush the memory but this was not
the case. what am i doing wrong? Thanks in advance
Below is simple example
import os, sys, time
import gc
import matplotlib
matplotlib.use('TKAgg')
import pylab
import matplotlib.cbook as cbook
pid = os.getpid()
a2 = os.popen('ps -p %d -o vsz' % pid).readlines()
print 'memory before all figures the figure is drawn: ' + str(a2[1])
pylab.ion()
fig_list = []
for i in range(10):
 fig_list.append(pylab.figure())
 val = cbook.report_memory(i)
 print i, val
pylab.show()
for fig in fig_list:
 pylab.close(fig)
gc.collect()
print 'uncollectable list:', gc.garbage
a2 = os.popen('ps -p %d -o vsz' % pid).readlines()
print 'memory after all figures are closed : ' + str(a2[1])
******results******************************
memory before all figures the figure is drawn: 35424
0 4981
1 4981
2 5493
3 6005
4 6005
5 6517
6 6517
7 7029
8 7541
9 7541
uncollectable list: []
memory after all figures are closed : 80808
thanks
kwabena
-- 
View this message in context: http://old.nabble.com/Memory-leak-tp27741668p27741668.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

--- On Sun, 2/28/10, David Goldsmith <d_l...@ya...> wrote:
> > >> > Question 2) is there some way I can add
> > pieces of the
> > >> array incrementally to
> > >> > the image into their proper place,
> i.e.,
> > modify the
> > >> following code:
> > >> >
> > >> >   ax.imshow(image[0:ny/2+1,
> 0:nx/2+1]) #
> > upper
> > >> left corner of image
> > >> >   ax.hold(True)
> > >> >   ax.imshow(argW[ny/2+1:-1,
> 0:nx/2+1]) #
> > lower
> > >> left corner of image
> > >> >   ax.imshow(argW[0:ny/2+1,
> nx/2+1:-1]) #
> > upper
> > >> right corner of image
> > >> >   ax.imshow(argW[ny/2+1:-1,
> nx/2+1:-1])
> > # lower
> > >> right corner of image
> > >>
> > >> Try the extents keyword argument. It let's
> you
> > specify the
> > >> corners of
> > >> the image in data coordinates.
> > >>
> > >> Ryan
> > >
> > > Hi, Ryan, thanks! Can you be a little more
> specific
> > as to how I should try that? I tried:
> > >
> > > ax.imshow(argW[0:ny/2+1, 0:nx/2+1], cmap_name,
> > extent=(0,nx/2,ny/2,0))
> > > ax.hold(True)
> > > ax.imshow(argW[ny/2+1:-1, 0:nx/2+1], cmap_name,
> > extent=(0,nx/2,ny,ny/2))
> > > ax.imshow(argW[0:ny/2+1, nx/2+1:-1], cmap_name,
> > extent=(nx/2,nx,ny/2,0))
> > > ax.imshow(argW[ny/2+1:-1, nx/2+1:-1], cmap_name,
> > extent=(nx/2,nx,ny,ny/2))
> > >
> > > which didn't work (I only got one "corner" - the
> last
> > one, I think - i.e., I think it's still just putting
> > subsequent images on top of prior ones).
> > 
> > Based on just a quick look, I'd make sure:
> > 
> > 1) To set the x and y limits appropriately:
> > 
> > ax.set_xlim(0, nx)
> > ax.set_ylim(ny, 0)
> 
> I'll try it out and report back.
Nope, still only getting the last corner. Let me give a little more of my code:
import numpy as N
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
w, h, DPI = (8.2, 6.2, 50)
fig = Figure(figsize=(w, h), 
 dpi=DPI,
 frameon=False)
ax = fig.add_subplot(1,1,1)
canvas = FigureCanvas(fig)
nx, xmin, xmax = (int(w*DPI), -0.5, 0.5)
ny, ymin, ymax = (int(h*DPI), 0.6, 1.2)
W = N.zeros((ny,nx),N.complex)
## Generate non-trivial W; unnecessary for code to run, I think
argW = N.angle(W)
ax.set_xlim(0, nx)
ax.set_ylim(ny, 0)
ax.imshow(argW[0:ny/2, 0:nx/2], extent=(0, nx/2 - 1, ny/2 - 1, 0))
ax.hold(True)
ax.imshow(argW[ny/2:-1, 0:nx/2], extent=(0, nx/2 - 1, ny, ny/2))
ax.imshow(argW[0:ny/2, nx/2:-1], extent=(nx/2, nx, ny/2 - 1, 0))
ax.imshow(argW[ny/2:-1, nx/2:-1], extent=(nx/2, nx, ny, ny/2))
canvas.print_figure(fid, dpi=DPI)
DG