matplotlib-users Mailing List for matplotlib

João et al.,
Thanks for the bug report. Mike D. has fixed the problem in svn. (I had 
moved the discussion to matplotlib-devel; I am just reporting back to 
matplotlib-users so this thread can be closed.)
Eric
Eric Firing wrote:
> wafels wrote:
>> Hello,
>>
>> I can confirm and extend this bug report. The axvline also moves to the
>> wrong position on resizing the matplotlib display window (Mac OS X 10.5.5,
>> Python 2.5.1, Matplotlib 0.98.3).
>>
>> Thanks
> 
> It looks like the transform for the line made by axvline is not getting 
> updated when view limits change. The problem is found in svn, after the 
> changes I made to axvline, as well as in 0.98.3. I can't track it down 
> right now.
> 
> Eric
> 
>>
>>
>> João Luís Silva-2 wrote:
>>> Hi,
>>>
>>> A vertical line on the x axis of a semilogy plot will be in the correct 
>>> position, but when saved with the save button of the toolbar it will be 
>>> placed in an incorrect position, although savefig will do the right 
>>> thing. Furthermore, zooming will not move the axvline correctly.
>>>
>>> Matplotlib version: 0.98.3
>>>
>>> Example script:
>>> -----------------------------------------
>>>
>>> import matplotlib.pyplot as pl
>>> import numpy as np
>>>
>>> x = np.linspace(0.0,1.0,100)
>>>
>>> pl.semilogy(x,x**2)
>>> pl.axvline(x=0.5,ls='--',color='k')
>>> pl.show()
>>> #pl.savefig("saved_image.png")
>>> -----------------------------------------
>>>
>>> image.png was saved using the toolbar, saved_image.png using savefig.
>>>
>>> Regards,
>>> João Silva

Thanks for the rapid fix Mike.
regards,
Gary
Michael Droettboom wrote:
> There is an explicit offset of one pixel on the left when it sets up a 
> clip box in Agg. I don't know why this is there, but it dates back to 
> 0.98.0, and earlier versions did something completely different. I can 
> only guess it was to compensate for an earlier bug in the precise 
> drawing of the axes rectangle. I can't explain why it would have 
> different behavior on Windows vs. Linux, though.
> 
> I have fixed this in SVN r6465 and am including a patch below (which 
> unfortunately requires a recompile).
> 
> Cheers,
> Mike

I've committed both of these things. The subplot()/polar() change seems 
tricky, so it may produce some breakage even though the "regression 
tests" are passing. Please let me know if you see anything strange 
after this change.
Mike
Ryan May wrote:
> Michael Droettboom wrote:
>> Thanks for updating the docstring. I actually saw this as a 
>> usability bug and have come up with a patch such that polar() (et al) 
>> will *replace* the current axes with a polar plot if it isn't already 
>> polar. This is (from the user's perspective) similar to how, for 
>> example, a histogram plot would work -- that is, you don't have to 
>> tell subplot you're about to plot a histogram.
>>
>> But Ryan's new docstring is not obsolete with respect to my proposed 
>> change. Both techniques will work, and in fact subplot(polar=True); 
>> polar(...) will be slightly faster since it avoids creating a linear 
>> axes which is subsequently thrown away.
>>
>> Any argument against committing my change?
>
> None here. I'm +1.
>
>> The polar theta tick formatter could be changed to call "round", I 
>> guess. Alternatively, it looks like '%0.0f' also does the right 
>> thing. I think that's generally what people would want for polar 
>> plots. This change would only affect polar theta ticks, so we don't 
>> need to worry about a change in behavior in standard Euclidean plots.
>>
>> Ryan's workaround (to get around this numerically external to 
>> matplotlib) is a good suggestion as well, but I think changing the 
>> formatter may be less surprising...
>
> I like the idea of using %0.0f. If I don't hear any objections, I'll 
> go ahead and make the change. It definitely will make things less 
> confusing for our users.
>
> Ryan
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Thanks for updating the docstring. I actually saw this as a usability 
> bug and have come up with a patch such that polar() (et al) will 
> *replace* the current axes with a polar plot if it isn't already polar. 
> This is (from the user's perspective) similar to how, for example, a 
> histogram plot would work -- that is, you don't have to tell subplot 
> you're about to plot a histogram.
> 
> But Ryan's new docstring is not obsolete with respect to my proposed 
> change. Both techniques will work, and in fact subplot(polar=True); 
> polar(...) will be slightly faster since it avoids creating a linear 
> axes which is subsequently thrown away.
> 
> Any argument against committing my change?
None here. I'm +1.
> The polar theta tick formatter could be changed to call "round", I 
> guess. Alternatively, it looks like '%0.0f' also does the right thing. 
> I think that's generally what people would want for polar plots. This 
> change would only affect polar theta ticks, so we don't need to worry 
> about a change in behavior in standard Euclidean plots.
> 
> Ryan's workaround (to get around this numerically external to 
> matplotlib) is a good suggestion as well, but I think changing the 
> formatter may be less surprising...
I like the idea of using %0.0f. If I don't hear any objections, I'll go 
ahead and make the change. It definitely will make things less 
confusing for our users.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Dec 2, 2008 at 12:09 PM, Eric Emsellem
<ems...@ob...> wrote:
> Really annoying but as mentioned before, I cannot get a set of commands which
> consistenly break the session, so...
Since there does not appear to be an easy diagnosis or fix, you may
want to consider switching your backend to the non-threaded tkagg
JDH

Ryan May wrote:
> On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner 
> <nw...@ia... <mailto:nw...@ia...>> 
> wrote:
>
> Thank you very much !
> It would be nice to have that information in the docstring
>
>
> Done.
Thanks for updating the docstring. I actually saw this as a usability 
bug and have come up with a patch such that polar() (et al) will 
*replace* the current axes with a polar plot if it isn't already polar. 
This is (from the user's perspective) similar to how, for example, a 
histogram plot would work -- that is, you don't have to tell subplot 
you're about to plot a histogram.
But Ryan's new docstring is not obsolete with respect to my proposed 
change. Both techniques will work, and in fact subplot(polar=True); 
polar(...) will be slightly faster since it avoids creating a linear 
axes which is subsequently thrown away.
Any argument against committing my change?
> 
>
> The next inquiry is related to xticks.
> I have added
>
> xticks(linspace(0,2*pi,24,endpoint=False))
>
> The difference between consecutive xticks is varying between 14
> and 16 degrees.
>
> For what reason ?
>
>
> Looks like roundoff error. For instance:
>
> linspace(0, 2*pi, 24)[7] * 180. / pi
> 104.999999999999
>
> If you format that with '%d', it becomes 104, not 105.
>
> Is there an accepted way of doing this rounding in matplotlib that 
> doesn't round in odd cases?
The polar theta tick formatter could be changed to call "round", I 
guess. Alternatively, it looks like '%0.0f' also does the right thing. 
I think that's generally what people would want for polar plots. This 
change would only affect polar theta ticks, so we don't need to worry 
about a change in behavior in standard Euclidean plots.
Ryan's workaround (to get around this numerically external to 
matplotlib) is a good suggestion as well, but I think changing the 
formatter may be less surprising...
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

>
> The next inquiry is related to xticks.
> I have added
>
> xticks(linspace(0,2*pi,24,endpoint=False))
>
> The difference between consecutive xticks is varying between 14 and 16
> degrees.
The following works around the roundoff for me:
xticks(linspace(0, 360, 24, endpoint=False) * pi/180.)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner
<nw...@ia...>wrote:
> Thank you very much !
> It would be nice to have that information in the docstring
>
Done.
> The next inquiry is related to xticks.
> I have added
>
> xticks(linspace(0,2*pi,24,endpoint=False))
>
> The difference between consecutive xticks is varying between 14 and 16
> degrees.
>
> For what reason ?
Looks like roundoff error. For instance:
linspace(0, 2*pi, 24)[7] * 180. / pi
104.999999999999
If you format that with '%d', it becomes 104, not 105.
Is there an accepted way of doing this rounding in matplotlib that doesn't
round in odd cases?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

running the last ipython version now (0.9.1), and it does not help (got stuck
the same way).
The difference now is that ipython provides a message:
Warning: Timeout for mainloop thread exceeded
switching to nonthreaded mode (until mainloop wakes up again)
It seems that ipython developers did catch the issue and made this message to be
delivered so that at least you can go on working with your session. However, I
cannot do anything with matplotlib after that message is given, and I have to
get out of the session and start again if I want to plot something...
This seems therefore linked to matplotlib and not ipython.. Just that now
ipython does not get stuck anymore but provide a message regarding the thread
issue. (Not very useful in this context for me unfortunately)
See the ipython scipy thread in fact :
http://lists.ipython.scipy.org/pipermail/ipython-user/2008-July/005628.html
So as far as I can tell this is a matplotlib bug and noone so far encountering
this problem has a really good idea why it occurs. Indeed the problem occurs
*only* when I launch matplotlib commands (after some time in my ipython session).
Really annoying but as mentioned before, I cannot get a set of commands which
consistenly break the session, so...
Eric
Yannick Copin wrote:
> I would say the pb is actually coming from ipython. I experienced it
> while using ipython-0.8.1, but I guess it disappeared starting with
> ipython-0.8.3 (see http://ipython.scipy.org/moin/WhatsNew083:
> "Multithreaded shells (used e.g. by matplotlib interaction) have been
> improved, reducing the possibility of corner case deadlocks."). I'm now
> using 0.8.4 and I don't remember I ever had this pb again.

On 2008年12月02日 12:43:14 -0500 Michael Droettboom <md...@st...>
wrote:
> Yeah. This is a known bug that was fixed since 0.98.1.
> 
Rats! Lets hope the Fedora guys are quick with the updating.
Thanks for ending my head-banging, though.
/W

On Tue, 2 Dec 2008 11:11:44 -0600 "Ryan May" <rm...@gm...> wrote:
> On Tue, Dec 2, 2008 at 10:12 AM, Wildemar Wildenburger <
> wil...@fr...> wrote:
> 
> > (snip)
> > polar([1,2,3,4],[1,3,4,2], "o")
> >
> > to my surprise does not give me 4 distinct points but rather some
> > interpolated points as well. This is highly unexpected, nay,
> > unwanted. It used to work well in Fedora 8 (don't know which
> > version I ran there).
> >
> > Fedora 10
> > Python 2.5.2
> > matplotlib 0.98.1
> >(snip)
> 
> Works for me on 0.98.3 and SVN HEAD. I get 4 blue dots. Can you
> send an image showing the output you're getting?
> 
See the attached screenshot.
thanks,
/W

Yeah. This is a known bug that was fixed since 0.98.1.
Cheers,
Mike
Ryan May wrote:
> On Tue, Dec 2, 2008 at 10:12 AM, Wildemar Wildenburger 
> <wil...@fr... <mailto:wil...@fr...>> wrote:
>
> Hi there,
>
> telling pyplot
>
> polar([1,2,3,4],[1,3,4,2], "o")
>
> to my surprise does not give me 4 distinct points but rather some
> interpolated points as well. This is highly unexpected, nay, unwanted.
> It used to work well in Fedora 8 (don't know which version I ran
> there).
>
> Fedora 10
> Python 2.5.2
> matplotlib 0.98.1
>
> Any ideas?
>
>
> Works for me on 0.98.3 and SVN HEAD. I get 4 blue dots. Can you send 
> an image showing the output you're getting?
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, 2 Dec 2008 11:14:48 -0600
 "Ryan May" <rm...@gm...> wrote:
> On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner
> <nw...@ia...>wrote:
> 
>> Hi all,
>>
>> If I run the attached example I obtain no polar plots, 
>>but a view like
>> plot(t,r_1) - for what reason ?
>>
> 
> You need to specify polar=True to the subplot commands. 
>Try this:
> 
> from pylab import subplot, polar, linspace, show
> from numpy import pi, sin, cos
> t = linspace(0,2*pi,20)
> r_1 = (1+sin(t))
> r_2 = (1+cos(t))
> subplot(211, polar=True)
> polar(t,r_1) #Or can use plot()
> subplot(212, polar=True)
> polar(t,r_2)
> show()
> 
> Ryan
> 
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
 
Hi Ryan,
Thank you very much !
It would be nice to have that information in the docstring
subplot(*args, **kwargs)
 Create a subplot command, creating axes with::
 subplot(numRows, numCols, plotNum)
 where *plotNum* = 1 is the first plot number and 
increasing *plotNums*
 fill rows first. max(*plotNum*) == *numRows* * 
*numCols*
The next inquiry is related to xticks.
I have added
xticks(linspace(0,2*pi,24,endpoint=False))
The difference between consecutive xticks is varying 
between 14 and 16 degrees.
For what reason ?
Nils

On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner
<nw...@ia...>wrote:
> Hi all,
>
> If I run the attached example I obtain no polar plots, but a view like
> plot(t,r_1) - for what reason ?
>
You need to specify polar=True to the subplot commands. Try this:
from pylab import subplot, polar, linspace, show
from numpy import pi, sin, cos
t = linspace(0,2*pi,20)
r_1 = (1+sin(t))
r_2 = (1+cos(t))
subplot(211, polar=True)
polar(t,r_1) #Or can use plot()
subplot(212, polar=True)
polar(t,r_2)
show()
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Dec 2, 2008 at 10:12 AM, Wildemar Wildenburger <
wil...@fr...> wrote:
> Hi there,
>
> telling pyplot
>
> polar([1,2,3,4],[1,3,4,2], "o")
>
> to my surprise does not give me 4 distinct points but rather some
> interpolated points as well. This is highly unexpected, nay, unwanted.
> It used to work well in Fedora 8 (don't know which version I ran
> there).
>
> Fedora 10
> Python 2.5.2
> matplotlib 0.98.1
>
> Any ideas?
>
Works for me on 0.98.3 and SVN HEAD. I get 4 blue dots. Can you send an
image showing the output you're getting?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi all,
 
If I run the attached example I obtain no polar plots, but 
a view like plot(t,r_1) - for what reason ?
Nils
python -i test_subplot_polar.py --verbose-helpful
$HOME=/home/nwagner
CONFIGDIR=/home/nwagner/.matplotlib
/usr/lib/python2.4/site-packages/matplotlib/__init__.py:662: 
UserWarning: Bad val "inputenc" on line #144
 "text.latex.unicode : inputenc # use "ucs" and 
"inputenc" LaTeX packages for handling
"
 in file "/home/nwagner/.matplotlib/matplotlibrc"
 Could not convert "inputenc" to boolean
 warnings.warn('Bad val "%s" on line #%d\n\t"%s"\n\tin 
file \
matplotlib data path 
/usr/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/nwagner/.matplotlib/matplotlibrc
matplotlib version 0.98.3
verbose.level helpful
interactive is False
units is False
platform is linux2
Using fontManager instance from 
/home/nwagner/.matplotlib/fontList.cache
backend GTKAgg version 2.5.3
findfont: Matching 
:family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=medium 
to Bitstream Vera Sans 
(/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf) 
with score of 1.000000
Found dvipng version 1.5

Hi there,
telling pyplot
 polar([1,2,3,4],[1,3,4,2], "o")
to my surprise does not give me 4 distinct points but rather some
interpolated points as well. This is highly unexpected, nay, unwanted.
It used to work well in Fedora 8 (don't know which version I ran
there).
Fedora 10
Python 2.5.2
matplotlib 0.98.1
Any ideas?
/W

All right, 
as information for all :
reinstalling cygwin from scratch, reinstalling python from scratch, and finaly matplotlib now works...
Cheers,
Thomas
**********************
Thomas Lecocq
Geologist
Ph.D.Student (Seismology)
Royal Observatory of Belgium
**********************
From: thl...@ms...
To: mat...@li...
Date: Tue, 2 Dec 2008 12:50:24 +0000
Subject: [Matplotlib-users] Cygwin1.dll error import pyplot
Hi all,
I've searched the mailing archive, and I can't find an anwser to my problem :
i'm running Python2.5 on a WinXP32 box. I just reinstalled cygwin to exclude a version-problem. Matplotlib version is 0.98.3 (got from easy_install matplotlib command)
i'm just trying this :
from matplotlib.pyplot import *
and the answer is :
 3 [main] ? (2808) C:\Python25\pythonw.exe: *** fatal error - Incompatible cygwin .dll -- incompatible per_process info 0 != 168
booooom...
I really don't know how to solve this...
Thanks a lot in advance for your help !
Thomas
**********************
Thomas Lecocq
Geologist
Ph.D.Student (Seismology)
Royal Observatory of Belgium
**********************

There is an explicit offset of one pixel on the left when it sets up a 
clip box in Agg. I don't know why this is there, but it dates back to 
0.98.0, and earlier versions did something completely different. I can 
only guess it was to compensate for an earlier bug in the precise 
drawing of the axes rectangle. I can't explain why it would have 
different behavior on Windows vs. Linux, though.
I have fixed this in SVN r6465 and am including a patch below (which 
unfortunately requires a recompile).
Cheers,
Mike
Modified: trunk/matplotlib/src/_backend_agg.cpp
===================================================================
--- trunk/matplotlib/src/_backend_agg.cpp	2008年12月01日 19:35:39 UTC (rev 6465)
+++ trunk/matplotlib/src/_backend_agg.cpp	2008年12月02日 15:27:23 UTC (rev 6466)
@@ -312,8 +312,8 @@
 
 double l, b, r, t;
 if (py_convert_bbox(cliprect.ptr(), l, b, r, t)) {
- rasterizer.clip_box(int(mpl_round(l)) + 1, height - int(mpl_round(b)),
- int(mpl_round(r)), height - int(mpl_round(t)));
+ rasterizer.clip_box(int(mpl_round(l)), height - int(mpl_round(b)),
+ int(mpl_round(r)), height - int(mpl_round(t)));
 }
 
 _VERBOSE("RendererAgg::set_clipbox done");

Hi all,
I've searched the mailing archive, and I can't find an anwser to my problem :
i'm running Python2.5 on a WinXP32 box. I just reinstalled cygwin to exclude a version-problem. Matplotlib version is 0.98.3 (got from easy_install matplotlib command)
i'm just trying this :
from matplotlib.pyplot import *
and the answer is :
 3 [main] ? (2808) C:\Python25\pythonw.exe: *** fatal error - Incompatible cygwin .dll -- incompatible per_process info 0 != 168
booooom...
I really don't know how to solve this...
Thanks a lot in advance for your help !
Thomas
**********************
Thomas Lecocq
Geologist
Ph.D.Student (Seismology)
Royal Observatory of Belgium
**********************

Thanks for verifying this Sünnje. It looks like an Agg bug. I just tried 
changing to the GTK backend in Linux and the problem disappears.
Gary
Sunnje L Basedow wrote:
> Hi Gary,
> I just tested your example, also on Intrepid with 0.98.3, and I get the
> exact same behaviour as you, with white pixels in the left column. But I
> have no idea why, sorry.
> Sünnje

Hi Gary,
I just tested your example, also on Intrepid with 0.98.3, and I get the
exact same behaviour as you, with white pixels in the left column. But I
have no idea why, sorry.
Sünnje
-----Original Message-----
From: Gary Ruben [mailto:gr...@bi...]
Sent: Tue 12/2/2008 11:13
To: mat...@li...
Subject: [Matplotlib-users] different behaviour in Windows and Linux
 
I'm wondering whether someone can reproduce the following problem I'm 
seeing in Ubuntu Intrepid.
I often use matplotlib to save images created with imshow to take 
advantage of matplotlib's colour maps. I've noticed that the behaviour 
is different for 0.98.3 between Windows XP-32 and Ubuntu Intrepid. I 
don't remember seeing this problem with earlier versions. This minimal 
example demonstrates the problem:
--
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm
px = 3
rcFig = {'figsize': (1, 1),
 'dpi': px,
 'subplot.bottom': 0,
 'subplot.left': 0,
 'subplot.right': 1,
 'subplot.top': 1,
 }
plt.rc('figure', **rcFig)
a = np.ones((px, px))
plt.axis('off')
plt.imshow(a, cmap=cm.gray)
plt.savefig('mpl_out.png', dpi=px)
--
In Windows I get the correct behaviour - in this case a 3x3 image with 
all black pixels:
bbb
bbb
bbb
However, in Linux the leftmost column of pixels is white
wbb
wbb
wbb
By the way, I think an imsave function that just saved an array as an 
image with a specified colourmap and clims would be a nice addition to 
matplotlib.image. Is there another way to achieve the same 1-to-1 array 
element-to-pixel image saving applying colourmaps and clims?
thanks,
Gary R.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I just realised that the example I gave may not be the best since it's 
not obvious what the autoscaling will do when all array values are 
equal. Nevertheless, even when the array contains a range of values and 
I use a greyscale colourmap, I'm seeing the leftmost pixel column set to 
all white when the array values in that column are all zeros and the 
image is written in Linux, whereas it's black when written in Windows.
Gary

I am indeed using ipython 0.8.1. Will try to upgrade and see how it goes.
Indeed this looks like the deadlocks people mentioned, within, as Xavier
emphasised, no way to CTRL-C it to kill it.
thanks for the tips
Eric
Yannick Copin wrote:
> Salut Eric,
> 
>> Date: 2008年12月01日 20:08:00 +0100
>> From: Eric Emsellem <ems...@ob...>
>> Subject: [Matplotlib-users] pylab or not... crashes or not
>>
>> - when I start a session with "ipython -pylab" I often get crashes
>> with my
>> session. When I mean "often", it means really often like once
>> everything 1/2h or
>> so. A crash means that the command I just sent gets stuck and the only
>> way for
>> me to get it back is to kill the PID of the ipython process...
> [...]
>> IPython 0.8.1 -- An enhanced Interactive Python.
> 
> I would say the pb is actually coming from ipython. I experienced it
> while using ipython-0.8.1, but I guess it disappeared starting with
> ipython-0.8.3 (see http://ipython.scipy.org/moin/WhatsNew083:
> "Multithreaded shells (used e.g. by matplotlib interaction) have been
> improved, reducing the possibility of corner case deadlocks."). I'm now
> using 0.8.4 and I don't remember I ever had this pb again.
> 
> See you! (and congrats ;-) )

I'm wondering whether someone can reproduce the following problem I'm 
seeing in Ubuntu Intrepid.
I often use matplotlib to save images created with imshow to take 
advantage of matplotlib's colour maps. I've noticed that the behaviour 
is different for 0.98.3 between Windows XP-32 and Ubuntu Intrepid. I 
don't remember seeing this problem with earlier versions. This minimal 
example demonstrates the problem:
--
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm
px = 3
rcFig = {'figsize': (1, 1),
 'dpi': px,
 'subplot.bottom': 0,
 'subplot.left': 0,
 'subplot.right': 1,
 'subplot.top': 1,
 }
plt.rc('figure', **rcFig)
a = np.ones((px, px))
plt.axis('off')
plt.imshow(a, cmap=cm.gray)
plt.savefig('mpl_out.png', dpi=px)
--
In Windows I get the correct behaviour - in this case a 3x3 image with 
all black pixels:
bbb
bbb
bbb
However, in Linux the leftmost column of pixels is white
wbb
wbb
wbb
By the way, I think an imsave function that just saved an array as an 
image with a specified colourmap and clims would be a nice addition to 
matplotlib.image. Is there another way to achieve the same 1-to-1 array 
element-to-pixel image saving applying colourmaps and clims?
thanks,
Gary R.