Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
The problem is the default quantizing of all rectilinear axis-aligned
lines (which includes the spines). They are "rounded" to the nearest
center pixels in order to make them less fuzzy.
However, there's actually a bug in the quantizer that your example
illustrates. Since the spine lines in your example have a stroke width
of 4 pixels, they should actually be rounded to the nearest pixel edge,
not nearest center pixel. So the quantizing is causing this slight
alignment problem *and* making the straight lines look fuzzier than they
should. I'm planning on writing a patch that will take stroke width
into account to address this. By coincidence only, this will also make
your example plot look more accurate (but that's dependent on the
specific scale being used).
The quantizing (once corrected) is a tradeoff to increase the sharpness
of rectilinear lines (which is important to many, including myself) at
the expense of some subpixel accuracy. The easy solution is to provide
a global flag (similar to path.simplify) that would turn off
quantization globally for those that want to live on the other side of
the tradeoff. The harder solution would be to quantize the axes (or
spines) and adjust the data accordingly based on the amount of shift.
I'm really not sure how to make the latter work without completely
reworking how quantization is currently implemented (the quantization is
pretty ignorant of anything "global" other than what it is currently
drawing).
Mike
On 06/11/2010 02:02 AM, Jason Grout wrote:
> Hi all,
>
> If you zoom in to the origin in the following figure:
>
> fig = plt.figure()
> ax = fig.add_subplot(1,1,1, aspect='equal')
> ax.plot([-1,1],[-1,1], color='blue')
> ax.set_xlim(-1.1,1.1)
> ax.set_ylim(-1.1,1.1)
> ax.spines['left'].set_position('zero')
> ax.spines['right'].set_color('none')
> ax.spines['bottom'].set_position('zero')
> ax.spines['top'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png',dpi=300)
>
> you'll see that the blue line isn't quite centered at the origin (at
> least the origin marked by the spines). It appears to hit just above or
> just to the left of the origin. Notice that there is a bit of blue
> coloring in the second quadrant, but none in the fourth. Notice also
> that there are more pixels colored just below the x-axis in quadrant 3
> than just above the axis in quadrant 1.
>
> Several of us Sage developers have been practically pulling out our hair
> trying to trace down why our plots seem to be shifted up or to the left
> by a pixel or so. I think the above example illustrates what is going on.
>
> Any ideas as to what is going on? I'm not sure if the problem is with
> the line or with the spines. The lines ax.plot([-1,1],[0,0]) and
> ax.plot([0,0],[-1,1]) seem to be right on center with the spines.
>
> Thanks,
>
> Jason
>
> --
> Jason Grout
>
>
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 06/11/2010 09:46 AM, Michael Droettboom wrote: > However, there's actually a bug in the quantizer that your example > illustrates. Since the spine lines in your example have a stroke width > of 4 pixels, they should actually be rounded to the nearest pixel edge, > not nearest center pixel. So the quantizing is causing this slight > alignment problem *and* making the straight lines look fuzzier than they > should. I'm planning on writing a patch that will take stroke width > into account to address this. By coincidence only, this will also make > your example plot look more accurate (but that's dependent on the > specific scale being used). > This specific bug is fixed in r8414. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug plotting very small values
Hi, Plotting some very small values (~1E-306) will break mpl with the error: File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 154, in draw_text self._renderer.draw_text_image(font.get_image(), int(x), int(y) + 1, angle, gc) OverflowError: cannot convert float infinity to long Very large values don't seem to be a problem and this bug seems to be backend independent. Also, for some reason the minimum double value representable in C and Python seem to be different... On my machine (i686 GNU/Linux, 32 bits Debian testing) the C DBL_MIN is ~1E-308, but Python seem to 1E-323 or so (Python 2.5.5). I'm using the latest mpl svn (rev 8414). Regards, João Silva Example script - import numpy as np import matplotlib.pyplot as plt n = 10 x = np.linspace(0.0,10.0,n) plt.plot(x,1E-306*np.ones(n)) plt.show() - -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 6/11/10 9:44 AM, Michael Droettboom wrote: > On 06/11/2010 09:46 AM, Michael Droettboom wrote: > >> However, there's actually a bug in the quantizer that your example >> illustrates. Since the spine lines in your example have a stroke width >> of 4 pixels, they should actually be rounded to the nearest pixel edge, >> not nearest center pixel. So the quantizing is causing this slight >> alignment problem *and* making the straight lines look fuzzier than they >> should. I'm planning on writing a patch that will take stroke width >> into account to address this. By coincidence only, this will also make >> your example plot look more accurate (but that's dependent on the >> specific scale being used). >> >> > This specific bug is fixed in r8414. > THANK YOU!!! And thanks for the nice explanation. Karl-Dieter Crisman and I figured there was some sort of pixel rounding issue somewhere, but it was above our heads to try to find it. Thanks, Jason -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] build_windowing option
I notice in setupext.py, a default is set for the setup.cfg build_windowing option, but it doesn't look like anything is ever actually read in from the configuration file to override the default. Also, the build_windowing option is not in the setup.cfg.template file. Is all of this intentional? Thanks, Jason -- Jason Grout -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 6/11/10 9:44 AM, Michael Droettboom wrote:
> On 06/11/2010 09:46 AM, Michael Droettboom wrote:
>
>> However, there's actually a bug in the quantizer that your example
>> illustrates. Since the spine lines in your example have a stroke width
>> of 4 pixels, they should actually be rounded to the nearest pixel edge,
>> not nearest center pixel. So the quantizing is causing this slight
>> alignment problem *and* making the straight lines look fuzzier than they
>> should. I'm planning on writing a patch that will take stroke width
>> into account to address this. By coincidence only, this will also make
>> your example plot look more accurate (but that's dependent on the
>> specific scale being used).
>>
>>
> This specific bug is fixed in r8414.
>
> Mike
>
>
I tested your fix, and now this example gives the same sort of problem
(note that in this case, the spine is 1 pixel wide; I've just changed
the dpi):
from matplotlib import pyplot as plt
import numpy as np
fig = plt.figure()
ax = fig.add_subplot(1,1,1, aspect='equal')
ax.plot([-1,1],[-1,1], color='blue')
ax.set_xlim(-1.1,1.1)
ax.set_ylim(-1.1,1.1)
ax.spines['left'].set_position('zero')
ax.spines['right'].set_color('none')
ax.spines['bottom'].set_position('zero')
ax.spines['top'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
fig.savefig('test.png',dpi=100)
It appears that the true origin is at the top left corner of the 1-pixel
intersection of the two spines in the above example.
Thanks again for your work on this!
Jason
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 06/11/2010 01:31 PM, jason-s...@creativetrax.com wrote: > On 6/11/10 9:44 AM, Michael Droettboom wrote: > >> On 06/11/2010 09:46 AM, Michael Droettboom wrote: >> >> >>> However, there's actually a bug in the quantizer that your example >>> illustrates. Since the spine lines in your example have a stroke width >>> of 4 pixels, they should actually be rounded to the nearest pixel edge, >>> not nearest center pixel. So the quantizing is causing this slight >>> alignment problem *and* making the straight lines look fuzzier than they >>> should. I'm planning on writing a patch that will take stroke width >>> into account to address this. By coincidence only, this will also make >>> your example plot look more accurate (but that's dependent on the >>> specific scale being used). >>> >>> >>> >> This specific bug is fixed in r8414. >> >> Mike >> >> >> > I tested your fix, and now this example gives the same sort of problem > (note that in this case, the spine is 1 pixel wide; I've just changed > the dpi): > That's exactly what I meant when I said "By coincidence only, this will also make your example plot look more accurate (but that's dependent on the specific scale being used)." This isn't a proper fix, other than to make even-width lines looking less fuzzy. The correct fix (to either make quanitizing an rcParam or to adjust the data based on it) is much more work. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Qt4 backend crashes when rcParam['toolbar'] is None
The Qt4 backend crashes with a Segmentation Fault when no toolbar is
requested. For example:
from matplotlib import pyplot as plt
from matplotlib import rcParams
rcParams['toolbar'] = 'None'
fig=plt.figure()
plt.show()
I have attached a possible patch, but since I've never really touched
the Qt4 backend before, thought I'd solicit some feedback before committing.
Mike
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
Index: backend_qt4.py
===
--- backend_qt4.py (revision 8402)
+++ backend_qt4.py (working copy)
@@ -314,16 +314,19 @@
self.window._destroying = False
self.toolbar = self._get_toolbar(self.canvas, self.window)
-self.window.addToolBar(self.toolbar)
-QtCore.QObject.connect(self.toolbar, QtCore.SIGNAL("message"),
-self.window.statusBar().showMessage)
+if self.toolbar is not None:
+self.window.addToolBar(self.toolbar)
+QtCore.QObject.connect(self.toolbar, QtCore.SIGNAL("message"),
+ self.window.statusBar().showMessage)
+tbs_height = self.toolbar.sizeHint().height()
+else:
+tbs_height = 0
# resize the main window so it will display the canvas with the
# requested size:
cs = canvas.sizeHint()
-tbs = self.toolbar.sizeHint()
sbs = self.window.statusBar().sizeHint()
-self.window.resize(cs.width(), cs.height()+tbs.height()+sbs.height())
+self.window.resize(cs.width(), cs.height()+tbs_height+sbs.height())
self.window.setCentralWidget(self.canvas)
@@ -335,7 +338,8 @@
def notify_axes_change( fig ):
# This will be called whenever the current axes is changed
- if self.toolbar != None: self.toolbar.update()
+ if self.toolbar is not None:
+ self.toolbar.update()
self.canvas.figure.add_axobserver( notify_axes_change )
def _widgetclosed( self ):
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 06/11/2010 07:39 AM, Michael Droettboom wrote: > On 06/11/2010 01:31 PM, jason-s...@creativetrax.com wrote: >> On 6/11/10 9:44 AM, Michael Droettboom wrote: >> >>> On 06/11/2010 09:46 AM, Michael Droettboom wrote: >>> >>> However, there's actually a bug in the quantizer that your example illustrates. Since the spine lines in your example have a stroke width of 4 pixels, they should actually be rounded to the nearest pixel edge, not nearest center pixel. So the quantizing is causing this slight alignment problem *and* making the straight lines look fuzzier than they should. I'm planning on writing a patch that will take stroke width into account to address this. By coincidence only, this will also make your example plot look more accurate (but that's dependent on the specific scale being used). >>> This specific bug is fixed in r8414. >>> >>> Mike >>> >>> >>> >> I tested your fix, and now this example gives the same sort of problem >> (note that in this case, the spine is 1 pixel wide; I've just changed >> the dpi): >> > That's exactly what I meant when I said "By coincidence only, this will > also make your example plot look more accurate (but that's dependent on > the specific scale being used)." This isn't a proper fix, other than to > make even-width lines looking less fuzzy. The correct fix (to either > make quanitizing an rcParam or to adjust the data based on it) is much > more work. I don't see how any reasonable algorithm could do such a data adjustment in general, so if the half-pixel inaccuracy is a problem, then I think using an rcParam to turn off quantizing is the way to go. It appears that the difficulty is that quantization is exposed at the python level only for collections, via iter_segments. Eric > > Mike > -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend crashes when rcParam['toolbar'] is None
On 06/11/2010 07:44 AM, Michael Droettboom wrote: > The Qt4 backend crashes with a Segmentation Fault when no toolbar is > requested. For example: Mike, Have the other backends been tested for the same problem? Eric > > from matplotlib import pyplot as plt > from matplotlib import rcParams > rcParams['toolbar'] = 'None' > fig=plt.figure() > plt.show() > > I have attached a possible patch, but since I've never really touched > the Qt4 backend before, thought I'd solicit some feedback before > committing. > > Mike > > > > -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > > > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 06/11/2010 01:54 PM, Eric Firing wrote: > On 06/11/2010 07:39 AM, Michael Droettboom wrote: > >> On 06/11/2010 01:31 PM, jason-s...@creativetrax.com wrote: >> >>> On 6/11/10 9:44 AM, Michael Droettboom wrote: >>> >>> On 06/11/2010 09:46 AM, Michael Droettboom wrote: > However, there's actually a bug in the quantizer that your example > illustrates. Since the spine lines in your example have a stroke width > of 4 pixels, they should actually be rounded to the nearest pixel edge, > not nearest center pixel. So the quantizing is causing this slight > alignment problem *and* making the straight lines look fuzzier than they > should. I'm planning on writing a patch that will take stroke width > into account to address this. By coincidence only, this will also make > your example plot look more accurate (but that's dependent on the > specific scale being used). > > > > This specific bug is fixed in r8414. Mike >>> I tested your fix, and now this example gives the same sort of problem >>> (note that in this case, the spine is 1 pixel wide; I've just changed >>> the dpi): >>> >>> >> That's exactly what I meant when I said "By coincidence only, this will >> also make your example plot look more accurate (but that's dependent on >> the specific scale being used)." This isn't a proper fix, other than to >> make even-width lines looking less fuzzy. The correct fix (to either >> make quanitizing an rcParam or to adjust the data based on it) is much >> more work. >> > I don't see how any reasonable algorithm could do such a data adjustment > in general, so if the half-pixel inaccuracy is a problem, then I think > using an rcParam to turn off quantizing is the way to go. > Yeah -- as I considered it further, I'm coming to the same conclusion. We could optimize for a single point, eg. (0, 0), but not for all ticks, gridlines etc. > It appears that the difficulty is that quantization is exposed at the > python level only for collections, via iter_segments. > Sort of. Lines (but none of the other artists) follow what is set by "set_snap" (the use of two terms for the same thing is also a problem, of course). This needs to be extended to other artists (and other relevant backend methods other than draw_path, if necessary). But I think for convenience, it should also be a global rcParam. Mike > Eric > > > >> Mike >> >> > > -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend crashes when rcParam['toolbar'] is None
Wx, Gtk, Tk all work for me. Couldn't test Qt "classic" as I don't have pyqt 3.x installed on my system. Mike On 06/11/2010 01:56 PM, Eric Firing wrote: > On 06/11/2010 07:44 AM, Michael Droettboom wrote: > >> The Qt4 backend crashes with a Segmentation Fault when no toolbar is >> requested. For example: >> > Mike, > > Have the other backends been tested for the same problem? > > Eric > > >> from matplotlib import pyplot as plt >> from matplotlib import rcParams >> rcParams['toolbar'] = 'None' >> fig=plt.figure() >> plt.show() >> >> I have attached a possible patch, but since I've never really touched >> the Qt4 backend before, thought I'd solicit some feedback before >> committing. >> >> Mike >> >> >> >> -- >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> >> >> >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 6/11/10 1:02 PM, Michael Droettboom wrote:
>
>> It appears that the difficulty is that quantization is exposed at the
>> python level only for collections, via iter_segments.
>>
>>
> Sort of. Lines (but none of the other artists) follow what is set by
> "set_snap" (the use of two terms for the same thing is also a problem,
> of course). This needs to be extended to other artists (and other
> relevant backend methods other than draw_path, if necessary). But I
> think for convenience, it should also be a global rcParam.
I think a work-around, then (at least it seems to work for me), is
setting both snap to False and antialiased to False for the spines.
That won't solve the issue for other horizontal lines, but at least it
takes care of having the correct origin for the intersection of the
spines. (Correct me if I'm wrong, of course!)
from matplotlib import pyplot as plt
import numpy as np
fig = plt.figure()
ax = fig.add_subplot(1,1,1, aspect='equal')
line1=ax.plot([-1,1],[0,0], color='blue')
line2=ax.plot([-1,1],[-1,1], color='red',zorder=5)
ax.set_xlim(-1.1,1.1)
ax.set_ylim(-1.1,1.1)
ax.spines['left'].set_position('zero')
ax.spines['left'].set_snap(False)
ax.spines['left'].set_antialiased(False)
ax.spines['right'].set_color('none')
ax.spines['bottom'].set_position('zero')
ax.spines['bottom'].set_snap(False)
ax.spines['bottom'].set_antialiased(False)
ax.spines['top'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
fig.savefig('test.png',dpi=100)
Thanks,
Jason
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 06/11/2010 02:38 PM, jason-s...@creativetrax.com wrote:
> On 6/11/10 1:02 PM, Michael Droettboom wrote:
>
>>
>>> It appears that the difficulty is that quantization is exposed at the
>>> python level only for collections, via iter_segments.
>>>
>>>
>>>
>> Sort of. Lines (but none of the other artists) follow what is set by
>> "set_snap" (the use of two terms for the same thing is also a problem,
>> of course). This needs to be extended to other artists (and other
>> relevant backend methods other than draw_path, if necessary). But I
>> think for convenience, it should also be a global rcParam.
>>
> I think a work-around, then (at least it seems to work for me), is
> setting both snap to False and antialiased to False for the spines.
> That won't solve the issue for other horizontal lines, but at least it
> takes care of having the correct origin for the intersection of the
> spines. (Correct me if I'm wrong, of course!)
>
> from matplotlib import pyplot as plt
> import numpy as np
> fig = plt.figure()
> ax = fig.add_subplot(1,1,1, aspect='equal')
> line1=ax.plot([-1,1],[0,0], color='blue')
> line2=ax.plot([-1,1],[-1,1], color='red',zorder=5)
> ax.set_xlim(-1.1,1.1)
> ax.set_ylim(-1.1,1.1)
> ax.spines['left'].set_position('zero')
> ax.spines['left'].set_snap(False)
> ax.spines['left'].set_antialiased(False)
> ax.spines['right'].set_color('none')
> ax.spines['bottom'].set_position('zero')
> ax.spines['bottom'].set_snap(False)
> ax.spines['bottom'].set_antialiased(False)
> ax.spines['top'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png',dpi=100)
>
I've committed a patch that provides a global snap setting in r8415.
Set the rcParam "path.snap" to False to turn off all snapping (though it
should be equivalent to your "set_snap" calls above -- just possibly
more convenient).
However, I think turning anti-aliasing off will give you the same
problem at some scales, as anti-aliasing has basically the same effect
as snapping: rounding to integral pixel values. Try an odd dpi such as
"67" for example.
Mike
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend crashes when rcParam['toolbar'] is None
On 06/11/2010 08:03 AM, Michael Droettboom wrote: > Wx, Gtk, Tk all work for me. Couldn't test Qt "classic" as I don't have > pyqt 3.x installed on my system. I just now installed pyqt3 (after some thrashing around--it turns out one needs the python-qt-dev package on ubuntu), and verified that qt3agg passes the test. Eric > > Mike > > On 06/11/2010 01:56 PM, Eric Firing wrote: >> On 06/11/2010 07:44 AM, Michael Droettboom wrote: >> >>> The Qt4 backend crashes with a Segmentation Fault when no toolbar is >>> requested. For example: >>> >> Mike, >> >> Have the other backends been tested for the same problem? >> >> Eric >> >> >>> from matplotlib import pyplot as plt >>> from matplotlib import rcParams >>> rcParams['toolbar'] = 'None' >>> fig=plt.figure() >>> plt.show() >>> >>> I have attached a possible patch, but since I've never really touched >>> the Qt4 backend before, thought I'd solicit some feedback before >>> committing. >>> >>> Mike >>> >>> >>> >>> -- >>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>> lucky parental unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> >>> >>> >>> ___ >>> Matplotlib-devel mailing list >>> Matplotlib-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >> >> -- >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] repeated calls to show() are now OK?
It seems that every couple of weeks, someone understandably asks why one can't call show() more than once in a script or session. However, I think that at least on all non-Mac backends, it now works. I have tested it (using ipython, with no threading) on: qtagg, qt4agg, wx, wxagg, gtk, gtkagg, tkagg, and fltkagg The only glitch is what appears to be an unrelated bug in fltkagg: clicking on the window-kill button of a sole open window doesn't have any effect. (There is also the difference in behavior: tkagg and fltkagg calls to show are non-blocking, while all the other backends block.) What is the situation with respect to the Mac backends? Is it time for us to change our documentation, and officially support the use of multiple calls to show()? If we can do it, I think it would remove one of the main stumbling blocks for newcomers. Eric -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plots shifted up or to the left a pixel or so
On 06/11/2010 09:09 AM, Michael Droettboom wrote:
> On 06/11/2010 02:38 PM, jason-s...@creativetrax.com wrote:
>> On 6/11/10 1:02 PM, Michael Droettboom wrote:
>>
>>>
It appears that the difficulty is that quantization is exposed at the
python level only for collections, via iter_segments.
>>> Sort of. Lines (but none of the other artists) follow what is set by
>>> "set_snap" (the use of two terms for the same thing is also a problem,
>>> of course). This needs to be extended to other artists (and other
>>> relevant backend methods other than draw_path, if necessary). But I
>>> think for convenience, it should also be a global rcParam.
>>>
>> I think a work-around, then (at least it seems to work for me), is
>> setting both snap to False and antialiased to False for the spines.
>> That won't solve the issue for other horizontal lines, but at least it
>> takes care of having the correct origin for the intersection of the
>> spines. (Correct me if I'm wrong, of course!)
>>
>> from matplotlib import pyplot as plt
>> import numpy as np
>> fig = plt.figure()
>> ax = fig.add_subplot(1,1,1, aspect='equal')
>> line1=ax.plot([-1,1],[0,0], color='blue')
>> line2=ax.plot([-1,1],[-1,1], color='red',zorder=5)
>> ax.set_xlim(-1.1,1.1)
>> ax.set_ylim(-1.1,1.1)
>> ax.spines['left'].set_position('zero')
>> ax.spines['left'].set_snap(False)
>> ax.spines['left'].set_antialiased(False)
>> ax.spines['right'].set_color('none')
>> ax.spines['bottom'].set_position('zero')
>> ax.spines['bottom'].set_snap(False)
>> ax.spines['bottom'].set_antialiased(False)
>> ax.spines['top'].set_color('none')
>> ax.xaxis.set_ticks_position('bottom')
>> ax.yaxis.set_ticks_position('left')
>> fig.savefig('test.png',dpi=100)
>>
> I've committed a patch that provides a global snap setting in r8415.
> Set the rcParam "path.snap" to False to turn off all snapping (though it
> should be equivalent to your "set_snap" calls above -- just possibly
> more convenient).
>
> However, I think turning anti-aliasing off will give you the same
> problem at some scales, as anti-aliasing has basically the same effect
> as snapping: rounding to integral pixel values. Try an odd dpi such as
> "67" for example.
I think you meant to say that aliasing is snapping, so with
anti-aliasing off, aliasing is universal, and all points are snapped to
pixels.
Eric
>
> Mike
>
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] repeated calls to show() are now OK?
On Fri, Jun 11, 2010 at 2:56 PM, Eric Firing wrote: > Is it time for us to change our documentation, and officially support > the use of multiple calls to show()? If we can do it, I think it would > remove one of the main stumbling blocks for newcomers. I don't have a problem allowing/supporting it, but it may be tricky if we expect it to have the same blocking/non-blocking behavior across backends. Ie, for the script that does for i in range(10): plt.plot(np.random.rand(10), 'o') plt.show() many users expect that to be blocking on each call to show and the script to continue after closing each figure. My guess is that different backends on different platforms might show different behavior -- some may block, others not. I haven't looked at your changes yet, but what is your opinion on this issue? JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] repeated calls to show() are now OK?
On 06/11/2010 10:09 AM, John Hunter wrote: > On Fri, Jun 11, 2010 at 2:56 PM, Eric Firing wrote: > >> Is it time for us to change our documentation, and officially support >> the use of multiple calls to show()? If we can do it, I think it would >> remove one of the main stumbling blocks for newcomers. > > I don't have a problem allowing/supporting it, but it may be tricky if > we expect it to have the same blocking/non-blocking behavior across > backends. Ie, for the script that does > > for i in range(10): > plt.plot(np.random.rand(10), 'o') > plt.show() > > many users expect that to be blocking on each call to show and the > script to continue after closing each figure. My guess is that > different backends on different platforms might show different > behavior -- some may block, others not. I haven't looked at your > changes yet, but what is your opinion on this issue? The only change I made was to the wx backend. (The basic idea was provided in a patch submitted nearly 3 years ago.) All the other non-Mac backends already handled multiple calls to show. I agree that the difference in blocking behavior is still a problem. I think that what we should do for now, *if* multiple calls to show work on the Mac (which I can't easily test), is change the documentation to correspond to the present situation, highlighting the real problem of different blocking behavior. Longer term, the ideal would be to universally support both blocking and non-blocking behavior, since there are valid use-cases for each. It would have to be coordinated with ipython. I suspect it is easier to add a blocking option to the non-blockers than to give the blockers a non-block option. I really don't know whether we are going to be able to make major progress on this, though. Guis are a pain, and multiple gui toolkits interacting with multiple environments yield major pain and frustration. Eric > > JDH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
