Is really matplotlib this slooow for displaying images ? (sorry again)

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 -
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

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 :slight_smile:

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 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 *
    rc('figure', figsize=(13,12))
    X = rand(1600,1600)

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 --Numeric -dTkAgg
    5.750u 1.730s 0:08.20 91.2% 0+0k 0+0io 3286pf+0w

    peds-pc311:~> time python --Numeric -dGTKAgg
    3.280u 0.840s 0:04.16 99.0% 0+0k 0+0io 4579pf+0w

    peds-pc311:~> time python --numarray -dTkAgg
    8.830u 1.100s 0:09.96 99.6% 0+0k 0+0io 3455pf+0w

    peds-pc311:~> time python --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

I'll spend some time with the profiler looking for some low hanging


# 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)
        raise RuntimeError(msg)
    except RuntimeError, msg:
        msg = raise_msg_to_str(msg)
        raise RuntimeError(msg)
    gci._current = ret
    return ret
figimage.__doc__ = Figure.figimage.__doc__ + """
Addition kwargs: hold = [True|False] overrides default hold state"""

thanks for the feedback.

To answer your questions:

- I have both Numeric and numarry but I am using
numarray in principle.

- Running in verbose mode, here is the output:

matplotlib data path /usr/share/matplotlib
loaded rc file /home/emsellem/.matplotlibrc
matplotlib version 0.65
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.0
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/emsellem/.ttffont.cache
Could not load matplotlib icon: 'module' object has no attribute 'window_set_default_icon_from_file'
backend GTKAgg version 2.0.0

- Then a VERY important note: yes indeed I am an astronomer
and I am used to have a fixed window (I first define its size
or use some default) and THEN ONLY load the image itself.
This is how I use ppgplot in python or Iraf, or Midas.
I indeed to not then use any interpolation scheme there.

- ALSO: there seems to be a bug in the figimage routine as
  it shows the image OUTSIDE an axis filled with white
(this may be because I am not doing the right thing though...)

- And finally here are the timing you asked for:
(there seem to be reasonable considering the difference

Hope this helps



Before correcting figima

time python --Numeric -dTkAgg
14.146u 2.363s 0:17.79 92.7% 0+0k 0+0io 10pf+0w

time python --Numeric -dGTKAgg
9.795u 1.697s 0:13.63 84.2% 0+0k 0+0io 12pf+0w

time python --numarray -dTkAgg
22.640u 1.443s 0:25.31 95.1% 0+0k 0+0io 13pf+0w

time python --numarray -dGTKAgg
15.125u 0.925s 0:16.26 98.6% 0+0k 0+0io 0pf+0w

After correcting figima

time python --Numeric -dTkAgg
10.432u 1.663s 0:12.37 97.7% 0+0k 0+0io 0pf+0w

time python --Numeric -dGTKAgg
5.209u 0.845s 0:06.10 99.0% 0+0k 0+0io 0pf+0w

time python --numarray -dTkAgg
16.391u 1.036s 0:17.96 96.9% 0+0k 0+0io 0pf+0w

time python --numarray -dGTKAgg
8.225u 0.546s 0:08.96 97.7% 0+0k 0+0io 0pf+0w


Observatoire de Lyon emsellem@...419...
9 av. Charles-Andre tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex fax: +33 4 78 86 83 86