matplotlib-users Mailing List for matplotlib

John Hunter wrote:
> On 3/26/07, Jeff Whitaker <js...@fa...> wrote:
>> John Hunter wrote:
> 
>> John: Nope, that has no effect. What does cla clean up that clf doesn't?
> 
> Well, it flushes all the lines, removes the ticks, that kind of thing.
> But fig.clear sets
> 
> self.axes = []
> 
> so if there are no references to the axes anywhere, gc.collect()
> should force a clean up and a purging of all the axes artists. Ie, it
> should matter if Axes.cla does self.lines=[] if the figure clear
> removes all references to the axes. I'm wondering if someone
> somewhere in mpl is keeping a reference to the axes....
It would have to be something like a growing list of axes, wouldn't it? 
Otherwise the old axes would be replaced by the new one on the next run 
through the loop, and it would not be a leak.
(The other leak, with interactive backends and nothing but 
pylab.figure(); pylab.close() in the loop is also keeping me baffled. 
It is not the same as the above, but it is the same sort of thing.)
Are there any python debugging tools that can show at the python level 
where memory is being used?
Eric

On 3/26/07, Jeff Whitaker <js...@fa...> wrote:
> John Hunter wrote:
> John: Nope, that has no effect. What does cla clean up that clf doesn't?
Well, it flushes all the lines, removes the ticks, that kind of thing.
 But fig.clear sets
self.axes = []
so if there are no references to the axes anywhere, gc.collect()
should force a clean up and a purging of all the axes artists. Ie, it
should matter if Axes.cla does self.lines=[] if the figure clear
removes all references to the axes. I'm wondering if someone
somewhere in mpl is keeping a reference to the axes....

John Hunter wrote:
> On 3/26/07, Jeff Whitaker <js...@fa...> wrote:
>
>> Jesper: For now I recommend adding 'pylab.cla()' after the fig.clear()
>> as a workaround. I don't really understand why that is necessary -
>> perhaps John or Eric can clarify whether this is indeed a bug.
>
> I suggest adding a gc.collect after the figure.clear() and see if
> this fixes things.
>
> JDH
John: Nope, that has no effect. What does cla clean up that clf doesn't?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On 3/26/07, Jeff Whitaker <js...@fa...> wrote:
> Jesper: For now I recommend adding 'pylab.cla()' after the fig.clear()
> as a workaround. I don't really understand why that is necessary -
> perhaps John or Eric can clarify whether this is indeed a bug.
 I suggest adding a gc.collect after the figure.clear() and see if
this fixes things.
JDH

On 3/26/07, lazardo <mas...@ya...> wrote:
>
> Thanks for your helpful response.
>
> I used wx, I'm mystified to as how to make the scroll bars bound the
> subplot. not the frame. The gtk example you pointed me to creates horizontal
> and vertical scrollbars around the whole frame, not within the subplot.
> i.e., if the subplot is very large , scrollbars bounding the subplot would
> be great..
This is not possible. The subplot is not a GUI widget in matplotlib,
it is part of the entire FigureCanvas, which is a widget. You can
make the Axes take up all of the figure area if you want
ax = axes([0,1,0,1])
but then you will not see you tick labels and axis labels as they will
be outside the canvas area....
JDH

Eric Firing wrote:
> Jeff Whitaker wrote:
>> Jesper Larsen wrote:
>>> Hi matplotlib users,
>>>
>>> I'm using matplotlib for a long running process. Unfortunately the 
>>> memory usage continue to grow as the process runs. I have appended a 
>>> simple example which illustrates this at the end of this mail. 
>>> Unfortunately I haven't figured out how to use the information 
>>> obtainable from gc for anything useful in this regards.
> [...]
>>> 
>> Jesper: Looks to me like the memory leak is not in Basemap, but 
>> somehow the fig.clear() is not working properly. Replacing the 
>> fig.clear() with pylab.gca() gets rid of the memory leak. I will 
>> investigate further ...
>>
>>
>> -Jeff
>>
>
> Jeff, this might be related to the leak illustrated in the attached 
> script, based on an earlier report. (I don't recall who reported it.)
>
> Eric
>
Eric: Don't think so, since Jesper's script leaks even when the backend 
is set to 'Agg' (while the one you sent doesn't).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

 Thanks for your helpful response.
 
 I used wx, I'm mystified to as how to make the scroll bars bound the subplot. not the frame. The gtk example you pointed me to creates horizontal and vertical scrollbars around the whole frame, not within the subplot. i.e., if the subplot is very large , scrollbars bounding the subplot would be great.. 
 
 Below is a sample of the code I attempted, let me know if I would need to make any corrections to it :
 
 import wx
 from matplotlib.axes import Subplot
 from matplotlib.figure import Figure
 from matplotlib.numerix import arange, sin, pi
 
 class ScrollbarFrame(wx.Frame):
 def __init__(self):
 wx.Frame.__init__(self, None, -1, 'Scrollbar example',size=(300,200))
 print "self"
 print self
 self.scroll = wx.ScrolledWindow(self, -1)
 print "self.scroll"
 print self.scroll
 self.figure = Figure(figsize=(5,4), dpi=100)
 self.axes = self.figure.add_subplot(111)
 t = arange(0.0,3.0,0.01)
 s = sin(2*pi*t)
 self.axes.plot(t,s)
 self.canvas = FigureCanvas(self, -1, self.figure)
 self.scroll.SetScrollbars(5,5,600,400)
 #self.scroll.FitInside()
 
 if __name__ == '__main__':
 app = wx.PySimpleApp()
 frame = ScrollbarFrame()
 frame.Show()
 app.MainLoop()
 
 Thanks,
 iyer
 
 John Hunter <jd...@gm...> wrote: On 3/19/07, lazardo wrote:
> I'm curious .. how can we include a scrollbar with a subplot, instead of the
> back and front arrows to view the subplot. Googling
> matplotlib+scrollbar+subplot brings up a very few results, so I guess it
> hasn't been attempted before.
The exact details depend on your GUI -- there is no generic support
for this in pylab but since you can embed matplotlib in the GUI widget
of your choice it is certainly possible. Below is a gtk example
embedding_in_gtk3.py from the matplotlib examples directory
import gtk
from matplotlib.axes import Subplot
from matplotlib.figure import Figure
from matplotlib.numerix import arange, sin, pi
# uncomment to select /GTK/GTKAgg/GTKCairo
#from matplotlib.backends.backend_gtk import FigureCanvasGTK as FigureCanvas
from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as
FigureCanvas
#from matplotlib.backends.backend_gtkcairo import FigureCanvasGTKCairo
as FigureCanvas
win = gtk.Window()
win.connect("destroy", lambda x: gtk.main_quit())
win.set_default_size(400,300)
win.set_title("Embedding in GTK")
f = Figure(figsize=(5,4), dpi=100)
a = f.add_subplot(111)
t = arange(0.0,3.0,0.01)
s = sin(2*pi*t)
a.plot(t,s)
sw = gtk.ScrolledWindow()
win.add (sw)
# A scrolled window border goes outside the scrollbars and viewport
sw.set_border_width (10)
# policy: ALWAYS, AUTOMATIC, NEVER
sw.set_policy (hscrollbar_policy=gtk.POLICY_AUTOMATIC,
 vscrollbar_policy=gtk.POLICY_ALWAYS)
canvas = FigureCanvas(f) # a gtk.DrawingArea
canvas.set_size_request(800,600)
sw.add_with_viewport (canvas)
win.show_all()
gtk.main()
 
 
 
---------------------------------
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.

Jeff Whitaker wrote:
> Jesper Larsen wrote:
>> Hi matplotlib users,
>>
>> I'm using matplotlib for a long running process. Unfortunately the memory 
>> usage continue to grow as the process runs. I have appended a simple example 
>> which illustrates this at the end of this mail. Unfortunately I haven't 
>> figured out how to use the information obtainable from gc for anything useful 
>> in this regards.
[...]
>> 
> Jesper: Looks to me like the memory leak is not in Basemap, but somehow 
> the fig.clear() is not working properly. Replacing the fig.clear() with 
> pylab.gca() gets rid of the memory leak. I will investigate further ...
> 
> 
> -Jeff
> 
Jeff, this might be related to the leak illustrated in the attached 
script, based on an earlier report. (I don't recall who reported it.)
Eric

I don't now if it's appropriate to post this here, but there's a new
Python/Pylons powered website that uses matplotlib. Think of it as a
success story for mpl:
http://www.marketshares.com.au
I'm not affiliated in any way with the site owner/creator.
Best,
Edin

On 3/24/07, Bill Baxter <wb...@gm...> wrote:
> Did you guys make a conscious decision to have the matplotlib list
> send replies only to the sender of the message rather than the list?
>
> This seems to be the default at SourceForge, so it's conceivable you
> just haven't bothered to change it. I've been on at least 10
> different mailing lists in the past 2 years or so, and of those
> matplotlib's is the only one I can recall being set up with default
> reply-to-sender rather than reply-to-list.
>
> I keep accidentally replying to senders only, so I thought I'd mention
> it. In the admin section on sourceforge there's a checkbox you can
> set to change the list from reply-to-sender to reply-to-list as the
> default.
>
> --bb
Hmm...
I had similar problems in the past, and was pointed at:
http://www.unicom.com/pw/reply-to-harmful.html
The above doc makes sense IMO. It's just after reading it that I
noticed the reply-to-all button in GMail.
Edin

On 3/26/07, Christopher Barker <Chr...@no...> wrote:
> Bill Baxter wrote:
> > Did you guys make a conscious decision to have the matplotlib list
> > send replies only to the sender of the message rather than the list?
>
> This was a deliberate decision. At the time there was a discussion,
> including a link to a very well written blog entry on the subject,
> advocating the current practice.
>
> As well written as that essay is, I think it's based on false
> assumptions and inappropriate priorities.
I'm personally happy to change it but I currently mostly just use the
defaults. The mailman instructions encourage list admins to make
reply to posters the default. When I started using a new mail client
for this list (gmail) I had to train myself to hit 'a' (reply to all)
rather than 'r' (reply to sender). Now I've mostly gotten the routine
down so it is mostly a nonissue for me.
>From mailman:
Reply_goes_to_list (general): Where are replies to list messages
directed? Poster is strongly recommended for most mailing lists.
This option controls what Mailman does to the Reply-To: header in
messages flowing through this mailing list. When set to Poster, no
Reply-To: header is added by Mailman, although if one is present in
the original message, it is not stripped. Setting this value to either
This list or Explicit address causes Mailman to insert a specific
Reply-To: header in all messages, overriding the header in the
original message if necessary (Explicit address inserts the value of
reply_to_address).
There are many reasons not to introduce or override the Reply-To:
header. One is that some posters depend on their own Reply-To:
settings to convey their valid return address. Another is that
modifying Reply-To: makes it much more difficult to send private
replies. See `Reply-To' Munging Considered Harmful for a general
discussion of this issue. See Reply-To Munging Considered Useful for a
dissenting opinion.
Some mailing lists have restricted posting privileges, with a parallel
list devoted to discussions. Examples are `patches' or `checkin'
lists, where software changes are posted by a revision control system,
but discussion about the changes occurs on a developers mailing list.
To support these types of mailing lists, select Explicit address and
set the Reply-To: address below to point to the parallel list.

Bill Baxter wrote:
> Did you guys make a conscious decision to have the matplotlib list
> send replies only to the sender of the message rather than the list?
This was a deliberate decision. At the time there was a discussion, 
including a link to a very well written blog entry on the subject, 
advocating the current practice.
As well written as that essay is, I think it's based on false 
assumptions and inappropriate priorities.
But I lost that one.
-Chris
PS: I almost sent this only to Bill!
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Jesper Larsen wrote:
> Hi matplotlib users,
>
> I'm using matplotlib for a long running process. Unfortunately the memory 
> usage continue to grow as the process runs. I have appended a simple example 
> which illustrates this at the end of this mail. Unfortunately I haven't 
> figured out how to use the information obtainable from gc for anything useful 
> in this regards.
>
> Kind regards,
> Jesper
>
>
> My system is:
>
> 
>> uname -a
>> 
> Linux sea 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007 i686 
> GNU/Linux
>
> 
>> python
>> 
> Python 2.4.4 (#1, Nov 16 2006, 13:39:46)
> [GCC 3.3.3 (Debian)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> import matplotlib
>>>> print matplotlib.__version__
>>>> 
> 0.87.6
> 
>>>> from matplotlib.toolkits import basemap
>>>> print basemap.__version__
>>>> 
> 0.9.4
>
> Test code:
>
> import os, gc
> import PyNGL.Nio as Nio
> from matplotlib.toolkits import basemap
> from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
> import pylab
>
> def report_memory(i):
> pid = os.getpid()
> a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> print i, ' ', a2[1],
> return int(a2[1].split()[1])
>
> def plot():
> #gc.set_debug(gc.DEBUG_LEAK)
> lon = pylab.linspace(-4.08300018311, 30.25, 207)
> lat = pylab.linspace(48.5499992371, 65.8499984741, 174)
> xo, yo = pylab.meshgrid(lon, lat)
> bmap = basemap.Basemap(-4, 48, 30, 66)
> xlon, ylat = bmap(xo,yo)
>
> fig = pylab.Figure()
> canvas = FigureCanvas(fig)
>
> i = 0
> while True:
> report_memory(i)
>
> fig.clear()
> cs = bmap.contourf(xlon, ylat, xo)
> del cs
>
> i += 1
>
> if __name__ == '__main__': plot()
>
> 
Jesper: For now I recommend adding 'pylab.cla()' after the fig.clear() 
as a workaround. I don't really understand why that is necessary - 
perhaps John or Eric can clarify whether this is indeed a bug.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

http://matplotlib.sourceforge.net/faq.html#SHOW
hth,
Alan Isaac

Hi,
I am totally new to pylab. I have just started using it. So please excuse if
my problem is too silly.
I have an application that has creates different plots for different input
parameters. I take in the input values and do a show(), This works perfectly
fine. Now after performing some operations I want a different pliot. So when
I generate a different plot and do a show(), the plot gets generated but
when I try to close it, it hangs. The structure of the program is something
like this.
def OnSubmit( self, event ):
 blah blah blah..
 sim = Simulator()
 sim.run()
So the graph is being plotted within the run method of Simulator class.
Could you please help me as to where I am going wrong?
Thanks,
Archana.

Hi Angelo,
I have faced a similar problem on using "from pylab import *"
but not exactly the same,
" matplotlib._ns_transforms.so: undefined symbol:
_ZNSs4_Rep20_S_empty_rep_storage "=20
=20
And I have found that this problem is deep rooted with gcc level and not
with matplotlib,
The python which you are using should be compiled with gcc level 3.4.6
(or may be higher, I have tested with gcc-3.4.6),when I compiled it
gcc-3.2.3 on redhat linux I was getting this error=20
=20
Hope it helps
--Regards
Rishi Khare
=20
Date: 2007年3月25日 11:25:50 -0500
From: ro...@yo...
Subject: [Matplotlib-users] Lots of Error Messages Upon Invoking "from
 pylab import *"
To: mat...@li...
Message-ID: <200...@ma...>
Content-Type: text/plain; charset=3DISO-8859-1
=20
Hello:
=20
I am using kanotix which is a very stable debian sid system. I intalled
the matplotlib package from the debian database successfully. It may
have pulled in python 2.4 as well. Please see what happens when I use
the command "from pylab import *" within python.
=20
Can someone please help me with this?
=20
Kind regards,
=20
Angelo
=20
rossi@KanotixBox:~$ python
Python 2.4.4 (#2, Jan 13 2007, 17:50:26) [GCC 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)] on linux2 Type "help", "copyright",
"credits" or "license" for more information.
>>> from pylab import *
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/lib/python2.4/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 197,
in ?
 import cm
 File "/usr/lib/python2.4/site-packages/matplotlib/cm.py", line 5, in ?
 import colors
 File "/usr/lib/python2.4/site-packages/matplotlib/colors.py", line 33,
in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File
"/usr/lib/python2.4/site-packages/matplotlib/numerix/__init__.py",
line 73, in ?
 import numpy
 File "/usr/lib/python2.4/site-packages/numpy/__init__.py", line 40, in
?
 import linalg
 File "/usr/lib/python2.4/site-packages/numpy/linalg/__init__.py", line
4, in ?
 from linalg import *
 File "/usr/lib/python2.4/site-packages/numpy/linalg/linalg.py", line
25, in ?
 from numpy.linalg import lapack_lite
ImportError: /usr/lib/atlas/liblapack.so.3: undefined symbol: ATL_ctbmv
=20
This email and any files transmitted with it are confidential, proprietar=
y
and intended solely for the individual or entity to whom they are address=
ed.
If you have received this email in error please delete it immediately.
=0D

Jesper Larsen wrote:
> Hi matplotlib users,
>
> I'm using matplotlib for a long running process. Unfortunately the memory 
> usage continue to grow as the process runs. I have appended a simple example 
> which illustrates this at the end of this mail. Unfortunately I haven't 
> figured out how to use the information obtainable from gc for anything useful 
> in this regards.
>
> Kind regards,
> Jesper
>
>
> My system is:
>
> 
>> uname -a
>> 
> Linux sea 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007 i686 
> GNU/Linux
>
> 
>> python
>> 
> Python 2.4.4 (#1, Nov 16 2006, 13:39:46)
> [GCC 3.3.3 (Debian)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> import matplotlib
>>>> print matplotlib.__version__
>>>> 
> 0.87.6
> 
>>>> from matplotlib.toolkits import basemap
>>>> print basemap.__version__
>>>> 
> 0.9.4
>
> Test code:
>
> import os, gc
> import PyNGL.Nio as Nio
> from matplotlib.toolkits import basemap
> from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
> import pylab
>
> def report_memory(i):
> pid = os.getpid()
> a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> print i, ' ', a2[1],
> return int(a2[1].split()[1])
>
> def plot():
> #gc.set_debug(gc.DEBUG_LEAK)
> lon = pylab.linspace(-4.08300018311, 30.25, 207)
> lat = pylab.linspace(48.5499992371, 65.8499984741, 174)
> xo, yo = pylab.meshgrid(lon, lat)
> bmap = basemap.Basemap(-4, 48, 30, 66)
> xlon, ylat = bmap(xo,yo)
>
> fig = pylab.Figure()
> canvas = FigureCanvas(fig)
>
> i = 0
> while True:
> report_memory(i)
>
> fig.clear()
> cs = bmap.contourf(xlon, ylat, xo)
> del cs
>
> i += 1
>
> if __name__ == '__main__': plot()
> 
Jesper: Looks to me like the memory leak is not in Basemap, but somehow 
the fig.clear() is not working properly. Replacing the fig.clear() with 
pylab.gca() gets rid of the memory leak. I will investigate further ...
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Bill Baxter wrote:
> gah! bitten by reply to sender once again.
Yes, this is a bit annoying.
> ---------- Forwarded message ----------
> From: Bill Baxter <wb...@gm...>
> Date: Mar 24, 2007 12:09 PM
> Subject: Re: [Matplotlib-users] interactive plots again
> To: Robert Cimrman <cim...@nt...>
> 
> 
> Are you sure that's threadsafe?
> With most windowing toolkits it's not safe to do GUI things from
> threads other than the main one. Other threads can only post a
> message to the main GUI thread. Depending on how fig.canvas.draw is
> implemented, calling it from another thread might not be kosher. But
> I take it you haven't seen any meltdowns so far, so maybe its
> implementation does the threadsafe message posting thing.
I am not sure (never used threads before), but it works for my
application and is very simple :). I do not have any GUI (meaning
top-level window with menus etc. driving some backend). Instead, I have
a command line program that interactively (pylab.ion()) pops up a figure
window and calls pylab.ioff(). Then from time to time it plots some data
and I want the figure window updated. There is no show() call while the
updating thread is running, so there is no GUI event loop, is that right?
Thank you for your comment, I am new to threading issues.
r.

Hi matplotlib users,
I'm using matplotlib for a long running process. Unfortunately the memory 
usage continue to grow as the process runs. I have appended a simple example 
which illustrates this at the end of this mail. Unfortunately I haven't 
figured out how to use the information obtainable from gc for anything useful 
in this regards.
Kind regards,
Jesper
My system is:
> uname -a
Linux sea 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007 i686 
GNU/Linux
> python
Python 2.4.4 (#1, Nov 16 2006, 13:39:46)
[GCC 3.3.3 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> print matplotlib.__version__
0.87.6
>>> from matplotlib.toolkits import basemap
>>> print basemap.__version__
0.9.4
Test code:
import os, gc
import PyNGL.Nio as Nio
from matplotlib.toolkits import basemap
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
import pylab
def report_memory(i):
 pid = os.getpid()
 a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
 print i, ' ', a2[1],
 return int(a2[1].split()[1])
def plot():
 #gc.set_debug(gc.DEBUG_LEAK)
 lon = pylab.linspace(-4.08300018311, 30.25, 207)
 lat = pylab.linspace(48.5499992371, 65.8499984741, 174)
 xo, yo = pylab.meshgrid(lon, lat)
 bmap = basemap.Basemap(-4, 48, 30, 66)
 xlon, ylat = bmap(xo,yo)
 fig = pylab.Figure()
 canvas = FigureCanvas(fig)
 i = 0
 while True:
 report_memory(i)
 fig.clear()
 cs = bmap.contourf(xlon, ylat, xo)
 del cs
 i += 1
if __name__ == '__main__': plot()

On 23/03/07, Eric Firing <ef...@ha...> wrote:
> Richard,
>
> I have made the requested change to imshow, so it is consistent with the
> new matshow, and I think it makes much more sense this way--but note
> that it depends on your rc value for image.origin. So, whenever you get
> mpl from svn, or the next release (whenever that occurs--not very soon,
> I suspect), I think you will find both matshow and imshow more to your
> liking.
>
Hi Eric
Thanks heaps - that was exactly what I was hoping for.
A small thing - I think the change might have induced a slight problem
in matshow - e.g. for a 3x3 image, the pixels are in the right place,
but the axis limits need to change from 0...3 to -0.5...2.5.
I'm impressed with the speed of the change - seems like a very helpful
community here.
cheers,
Richard