Hi, I am using:
> IPython 0.6.6 with Python 2.3.3 and matplotlib-0.65
OK, too bad, one of the most common causes of slow behavior on earlier
versions of matplotlib was a numeric/numarray incompatibility setting
as discussed here - http://matplotlib.sourceforge.net/faq.html#SLOW.
But with 0.65, this shouldn't be a problem. But just to be certain
- do you have Numeric and numarray on your system?
- what is the output of any test script when run with
--verbose-helpful.
It is important that you are not mixing numeric and numarray in your
code, because then matplotlib falls back on the python sequence
protocol. So I just want to insure that you are using numarray
consistently and that matplotlib knows it.
> (checked that this is indeed the case)
> Eric P.S.: by the way, just to let you know (and I will pass
> the message on the forum) I am sincerely very impressed by
> matplotlib in general (in fact 5 people just switched to it
> in the last 2 weeks and our group only amounts to 10 people
> so 1/2 still to convince!). So this kind of ''negative''
> feedback/question should not undermine the rest of the soft
> for sure!!!
I passed it on already. I suspect there are a number of others who
are interested in and can contribute to this discussion so I'll keep
this on list for a bit. Thanks for the moral support 
A bit of background: as Arnd pointed out, imshow is probably doing a
lot more under the hood than you need, so I suggest we stick with
figimage for a while. I assume you're an astronomer, since you
mentioned IRAF, no? Perry Greenfield, also an astronomer, suggested
figimage because he mainly wanted a pixel dump of his data, with no
interpolation that imshow provides.
Do you need color mapping, or mainly grayscale? The reason I ask is
that for simplicity of coding I convert everything to an RGBA under
the hood, which is obviously inefficient in memory and CPU time. At
some point (maybe now), we'll have to special case grayscale for
people who can't pay those extra costs. I don't know if this is where
your bottleneck is.
So assuming figimage for now, I wrote a test script to get some
numbers for comparison. Then I noticed I had introduced a bug in 0.65
in figimage when I wrongly added "hold" control to figimage, where it
doesn't below. So replace figimage in pylab.py with the function I'm
including below before running any tests.
Since most people can't fit a 1600x1600 image on screen (I can't),
we'll need a big figure window at least to get most of it.. That's
what the figsize command is for. FYI, my suspicion is we should be
able to get acceptable performance for 1600x1600 or 2000x2000 and
images of this magnitude, with some basic refactoring and
optimization. I doubt we'll get 20k x 20k in the forseeable future,
in large part because the underlying image library from antigrain only
does 4096x4096.
With this script, I'm running in interactive mode ("ion") so the
figure will be created when the figimage call is made, and then will
immediately terminate rather than go into the tk mainloop since show
is called.
from pylab import *
ion()
rc('figure', figsize=(13,12))
X = rand(1600,1600)
figimage(X, cmap=cm.hot)
#show()
Here are my numbers. Note I can get almost a 2x performance boost
switching to GTKAgg - there are known performance issues blitting a
large image to tkinter. Is GTKAgg as possibility for you?
peds-pc311:~> time python test.py --Numeric -dTkAgg
5.750u 1.730s 0:08.20 91.2% 0+0k 0+0io 3286pf+0w
peds-pc311:~> time python test.py --Numeric -dGTKAgg
3.280u 0.840s 0:04.16 99.0% 0+0k 0+0io 4579pf+0w
peds-pc311:~> time python test.py --numarray -dTkAgg
8.830u 1.100s 0:09.96 99.6% 0+0k 0+0io 3455pf+0w
peds-pc311:~> time python test.py --numarray -dGTKAgg
4.730u 0.560s 0:05.36 98.6% 0+0k 0+0io 4747pf+0w
with a 3GHz P4 with 1GB of RAM. How do the numbers for your system
compare?
I'll spend some time with the profiler looking for some low hanging
fruit.
JDH
# the modified figimage function
def figimage(*args, **kwargs):
# allow callers to override the hold state by passing hold=True|False
try: ret = gcf().figimage(*args, **kwargs)
except ValueError, msg:
msg = raise_msg_to_str(msg)
error_msg(msg)
hold(b)
raise RuntimeError(msg)
except RuntimeError, msg:
msg = raise_msg_to_str(msg)
error_msg(msg)
hold(b)
raise RuntimeError(msg)
draw_if_interactive()
gci._current = ret
return ret
figimage.__doc__ = Figure.figimage.__doc__ + """
Addition kwargs: hold = [True|False] overrides default hold state"""