different behaviour in Windows and Linux

Community matplotlib-users
1

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:gruben@…636…]
Sent: Tue 12/2/2008 11:13
To: matplotlib-users@lists.sourceforge.net
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

2

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

3

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");

4

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