Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Close
From: Kaushik Ghose <Kaushik_G<hose@hm...>  20081228 01:05:47

Hi John, OK. I've managed to pare it down to the following pattern: import pylab N = 1000 x = pylab.zeros(200) x[1] = .5 x[2:24] = 1.0 x[24] = .5 x[26] = .5 x[27:49] = 1.0 x[49] = .5 x = pylab.tile(x, 100) pylab.plot(x) The above code is sufficient to repeat the glitch (just resize the window to check this). The halfway values (0.5) are important  if we have a straight jump the glitch isn't visible. I'm sorry but I couldn't find path.py under /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ so I couldn't try it out. (Is it under a different place in mac?) thanks Kaushik John Hunter wrote: > On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose > <Kaushik_Ghose@...> wrote: >> Hi Gang, >> >> I was plotting some data collected from an ADC and noticed an odd aliasing >> issue. Please see the images on the following site. >> >> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >> >> I wonder if there is any way to avoid this kind of aliasing. I vaguely remember >> our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's >> plotting to be superior to MATLAB's in every way (except for 3D) and it would be >> nice if aliasing could be handled gracefully. > > I'm almost certain this is a result of the path simplification logic. > Could you upload some sample data and a self contained script so we > can test? > You can test this by editing sitepackages/path.py and replacing:: > > self.should_simplify = (len(vertices) >= 128 and > (codes is None or np.all(codes <= Path.LINETO))) > > with:: > > self.should_simplify = False > > Michael, perhaps we could override path.should_simplify with an rc or > line property? > >> Also, thanks for the excellent binary packages for Mac! > > Thanks for testing them! 
From: Kaushik Ghose <Kaushik_G<hose@hm...>  20081227 16:28:37

Hi Gang, I was plotting some data collected from an ADC and noticed an odd aliasing issue. Please see the images on the following site. http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html I wonder if there is any way to avoid this kind of aliasing. I vaguely remember our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's plotting to be superior to MATLAB's in every way (except for 3D) and it would be nice if aliasing could be handled gracefully. Also, thanks for the excellent binary packages for Mac! Many thanks Kaushik 
From: John Hunter <jdh2358@gm...>  20081227 16:43:37

On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose <Kaushik_Ghose@...> wrote: > Hi Gang, > > I was plotting some data collected from an ADC and noticed an odd aliasing > issue. Please see the images on the following site. > > http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html > > I wonder if there is any way to avoid this kind of aliasing. I vaguely remember > our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's > plotting to be superior to MATLAB's in every way (except for 3D) and it would be > nice if aliasing could be handled gracefully. I'm almost certain this is a result of the path simplification logic. Could you upload some sample data and a self contained script so we can test? You can test this by editing sitepackages/path.py and replacing:: self.should_simplify = (len(vertices) >= 128 and (codes is None or np.all(codes <= Path.LINETO))) with:: self.should_simplify = False Michael, perhaps we could override path.should_simplify with an rc or line property? > Also, thanks for the excellent binary packages for Mac! Thanks for testing them! 
From: Kaushik Ghose <Kaushik_G<hose@hm...>  20081228 01:05:47

Hi John, OK. I've managed to pare it down to the following pattern: import pylab N = 1000 x = pylab.zeros(200) x[1] = .5 x[2:24] = 1.0 x[24] = .5 x[26] = .5 x[27:49] = 1.0 x[49] = .5 x = pylab.tile(x, 100) pylab.plot(x) The above code is sufficient to repeat the glitch (just resize the window to check this). The halfway values (0.5) are important  if we have a straight jump the glitch isn't visible. I'm sorry but I couldn't find path.py under /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ so I couldn't try it out. (Is it under a different place in mac?) thanks Kaushik John Hunter wrote: > On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose > <Kaushik_Ghose@...> wrote: >> Hi Gang, >> >> I was plotting some data collected from an ADC and noticed an odd aliasing >> issue. Please see the images on the following site. >> >> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >> >> I wonder if there is any way to avoid this kind of aliasing. I vaguely remember >> our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's >> plotting to be superior to MATLAB's in every way (except for 3D) and it would be >> nice if aliasing could be handled gracefully. > > I'm almost certain this is a result of the path simplification logic. > Could you upload some sample data and a self contained script so we > can test? > You can test this by editing sitepackages/path.py and replacing:: > > self.should_simplify = (len(vertices) >= 128 and > (codes is None or np.all(codes <= Path.LINETO))) > > with:: > > self.should_simplify = False > > Michael, perhaps we could override path.should_simplify with an rc or > line property? > >> Also, thanks for the excellent binary packages for Mac! > > Thanks for testing them! 
From: Kaushik Ghose <Kaushik_G<hose@hm...>  20081228 01:09:16

PS. In the code just disregard the line N = 1000  it does nothing. Ghose, Kaushik wrote: > Hi John, > > OK. I've managed to pare it down to the following pattern: > > import pylab > > N = 1000 > x = pylab.zeros(200) > x[1] = .5 > x[2:24] = 1.0 > x[24] = .5 > x[26] = .5 > x[27:49] = 1.0 > x[49] = .5 > x = pylab.tile(x, 100) > pylab.plot(x) > > > The above code is sufficient to repeat the glitch (just resize the window to > check this). The halfway values (0.5) are important  if we have a straight > jump the glitch isn't visible. > > I'm sorry but I couldn't find path.py under > > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ > > so I couldn't try it out. (Is it under a different place in mac?) > > thanks > Kaushik > > > > John Hunter wrote: >> On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose >> <Kaushik_Ghose@...> wrote: >>> Hi Gang, >>> >>> I was plotting some data collected from an ADC and noticed an odd aliasing >>> issue. Please see the images on the following site. >>> >>> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >>> >>> I wonder if there is any way to avoid this kind of aliasing. I vaguely remember >>> our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's >>> plotting to be superior to MATLAB's in every way (except for 3D) and it would be >>> nice if aliasing could be handled gracefully. >> I'm almost certain this is a result of the path simplification logic. >> Could you upload some sample data and a self contained script so we >> can test? >> You can test this by editing sitepackages/path.py and replacing:: >> >> self.should_simplify = (len(vertices) >= 128 and >> (codes is None or np.all(codes <= Path.LINETO))) >> >> with:: >> >> self.should_simplify = False >> >> Michael, perhaps we could override path.should_simplify with an rc or >> line property? >> >>> Also, thanks for the excellent binary packages for Mac! >> Thanks for testing them! > >  > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers 
From: Michael Droettboom <mdroe@st...>  20081229 14:26:56

You can hold off on updating. I am actually able to see it now, even on SVN HEAD. I'll look further and see if I can find a workaround. Cheers, Mike Kaushik Ghose wrote: > Hi Mike, > > I'm using 0.98.3 with the TkAgg backend on Mac OS X. > > I will update matplotlib from the site and try again. My attempt to > use GtkAgg failed presumably because I don't have things set up with > GTk on my Mac. > > best > Kaushik > > Michael Droettboom wrote: >> I'm not able to reproduce this on matplotlib SVN head with the GtkAgg >> backend. Which version and backend are you using? >> >> Mike >> >> Kaushik Ghose wrote: >>> PS. In the code just disregard the line N = 1000  it does nothing. >>> >>> Ghose, Kaushik wrote: >>> >>>> Hi John, >>>> >>>> OK. I've managed to pare it down to the following pattern: >>>> >>>> import pylab >>>> >>>> N = 1000 >>>> x = pylab.zeros(200) >>>> x[1] = .5 >>>> x[2:24] = 1.0 >>>> x[24] = .5 >>>> x[26] = .5 >>>> x[27:49] = 1.0 >>>> x[49] = .5 >>>> x = pylab.tile(x, 100) >>>> pylab.plot(x) >>>> >>>> >>>> The above code is sufficient to repeat the glitch (just resize the >>>> window to >>>> check this). The halfway values (0.5) are important  if we have a >>>> straight >>>> jump the glitch isn't visible. >>>> >>>> I'm sorry but I couldn't find path.py under >>>> >>>> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ >>>> >>>> >>>> so I couldn't try it out. (Is it under a different place in mac?) >>>> >>>> thanks >>>> Kaushik >>>> >>>> >>>> >>>> John Hunter wrote: >>>> >>>>> On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose >>>>> <Kaushik_Ghose@...> wrote: >>>>> >>>>>> Hi Gang, >>>>>> >>>>>> I was plotting some data collected from an ADC and noticed an odd >>>>>> aliasing >>>>>> issue. Please see the images on the following site. >>>>>> >>>>>> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >>>>>> >>>>>> >>>>>> I wonder if there is any way to avoid this kind of aliasing. I >>>>>> vaguely remember >>>>>> our old archfoe (MATLAB) handles this gracefully. I have found >>>>>> matplotlib's >>>>>> plotting to be superior to MATLAB's in every way (except for 3D) >>>>>> and it would be >>>>>> nice if aliasing could be handled gracefully. >>>>>> >>>>> I'm almost certain this is a result of the path simplification logic. >>>>> Could you upload some sample data and a self contained script so we >>>>> can test? >>>>> You can test this by editing sitepackages/path.py and replacing:: >>>>> >>>>> self.should_simplify = (len(vertices) >= 128 and >>>>> (codes is None or np.all(codes <= >>>>> Path.LINETO))) >>>>> >>>>> with:: >>>>> >>>>> self.should_simplify = False >>>>> >>>>> Michael, perhaps we could override path.should_simplify with an rc or >>>>> line property? >>>>> >>>>> >>>>>> Also, thanks for the excellent binary packages for Mac! >>>>>> >>>>> Thanks for testing them! >>>>> >>>>  >>>> >>>> _______________________________________________ >>>> Matplotlibusers mailing list >>>> Matplotlibusers@... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >>>> >>>  >>> >>> _______________________________________________ >>> Matplotlibusers mailing list >>> Matplotlibusers@... >>> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >>> >> >>  >> Michael Droettboom >> Science Software Branch >> Operations and Engineering Division >> Space Telescope Science Institute >> Operated by AURA for NASA >>  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: Michael Droettboom <mdroe@st...>  20081229 12:51:17

I'm not able to reproduce this on matplotlib SVN head with the GtkAgg backend. Which version and backend are you using? Mike Kaushik Ghose wrote: > PS. In the code just disregard the line N = 1000  it does nothing. > > Ghose, Kaushik wrote: > >> Hi John, >> >> OK. I've managed to pare it down to the following pattern: >> >> import pylab >> >> N = 1000 >> x = pylab.zeros(200) >> x[1] = .5 >> x[2:24] = 1.0 >> x[24] = .5 >> x[26] = .5 >> x[27:49] = 1.0 >> x[49] = .5 >> x = pylab.tile(x, 100) >> pylab.plot(x) >> >> >> The above code is sufficient to repeat the glitch (just resize the window to >> check this). The halfway values (0.5) are important  if we have a straight >> jump the glitch isn't visible. >> >> I'm sorry but I couldn't find path.py under >> >> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ >> >> so I couldn't try it out. (Is it under a different place in mac?) >> >> thanks >> Kaushik >> >> >> >> John Hunter wrote: >> >>> On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose >>> <Kaushik_Ghose@...> wrote: >>> >>>> Hi Gang, >>>> >>>> I was plotting some data collected from an ADC and noticed an odd aliasing >>>> issue. Please see the images on the following site. >>>> >>>> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >>>> >>>> I wonder if there is any way to avoid this kind of aliasing. I vaguely remember >>>> our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's >>>> plotting to be superior to MATLAB's in every way (except for 3D) and it would be >>>> nice if aliasing could be handled gracefully. >>>> >>> I'm almost certain this is a result of the path simplification logic. >>> Could you upload some sample data and a self contained script so we >>> can test? >>> You can test this by editing sitepackages/path.py and replacing:: >>> >>> self.should_simplify = (len(vertices) >= 128 and >>> (codes is None or np.all(codes <= Path.LINETO))) >>> >>> with:: >>> >>> self.should_simplify = False >>> >>> Michael, perhaps we could override path.should_simplify with an rc or >>> line property? >>> >>> >>>> Also, thanks for the excellent binary packages for Mac! >>>> >>> Thanks for testing them! >>> >>  >> _______________________________________________ >> Matplotlibusers mailing list >> Matplotlibusers@... >> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >> > >  > _______________________________________________ > Matplotlibusers mailing list > Matplotlibusers@... > https://lists.sourceforge.net/lists/listinfo/matplotlibusers >  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: Kaushik Ghose <Kaushik_G<hose@hm...>  20081229 14:21:51

Hi Mike, I'm using 0.98.3 with the TkAgg backend on Mac OS X. I will update matplotlib from the site and try again. My attempt to use GtkAgg failed presumably because I don't have things set up with GTk on my Mac. best Kaushik Michael Droettboom wrote: > I'm not able to reproduce this on matplotlib SVN head with the GtkAgg > backend. Which version and backend are you using? > > Mike > > Kaushik Ghose wrote: >> PS. In the code just disregard the line N = 1000  it does nothing. >> >> Ghose, Kaushik wrote: >> >>> Hi John, >>> >>> OK. I've managed to pare it down to the following pattern: >>> >>> import pylab >>> >>> N = 1000 >>> x = pylab.zeros(200) >>> x[1] = .5 >>> x[2:24] = 1.0 >>> x[24] = .5 >>> x[26] = .5 >>> x[27:49] = 1.0 >>> x[49] = .5 >>> x = pylab.tile(x, 100) >>> pylab.plot(x) >>> >>> >>> The above code is sufficient to repeat the glitch (just resize the window to >>> check this). The halfway values (0.5) are important  if we have a straight >>> jump the glitch isn't visible. >>> >>> I'm sorry but I couldn't find path.py under >>> >>> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ >>> >>> so I couldn't try it out. (Is it under a different place in mac?) >>> >>> thanks >>> Kaushik >>> >>> >>> >>> John Hunter wrote: >>> >>>> On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose >>>> <Kaushik_Ghose@...> wrote: >>>> >>>>> Hi Gang, >>>>> >>>>> I was plotting some data collected from an ADC and noticed an odd aliasing >>>>> issue. Please see the images on the following site. >>>>> >>>>> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >>>>> >>>>> I wonder if there is any way to avoid this kind of aliasing. I vaguely remember >>>>> our old archfoe (MATLAB) handles this gracefully. I have found matplotlib's >>>>> plotting to be superior to MATLAB's in every way (except for 3D) and it would be >>>>> nice if aliasing could be handled gracefully. >>>>> >>>> I'm almost certain this is a result of the path simplification logic. >>>> Could you upload some sample data and a self contained script so we >>>> can test? >>>> You can test this by editing sitepackages/path.py and replacing:: >>>> >>>> self.should_simplify = (len(vertices) >= 128 and >>>> (codes is None or np.all(codes <= Path.LINETO))) >>>> >>>> with:: >>>> >>>> self.should_simplify = False >>>> >>>> Michael, perhaps we could override path.should_simplify with an rc or >>>> line property? >>>> >>>> >>>>> Also, thanks for the excellent binary packages for Mac! >>>>> >>>> Thanks for testing them! >>>> >>>  >>> _______________________________________________ >>> Matplotlibusers mailing list >>> Matplotlibusers@... >>> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >>> >>  >> _______________________________________________ >> Matplotlibusers mailing list >> Matplotlibusers@... >> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >> > >  > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > 
From: Michael Droettboom <mdroe@st...>  20081229 14:44:28

This is now fixed in SVN HEAD. Two changes were made: a) Be more conservative about when segments are simplified based on their length b) Honor the (already existing) path.simplify rcParam in the *Agg backends. John's suggested patch is also a valid workaround, if you don't want to track SVN. path.py lives in /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/matplotlib on a Mac. Simply replace the line where should_simplify is set to "self.should_simplify = False" Mike Michael Droettboom wrote: > You can hold off on updating. I am actually able to see it now, even on > SVN HEAD. I'll look further and see if I can find a workaround. > > Cheers, > Mike > > Kaushik Ghose wrote: > >> Hi Mike, >> >> I'm using 0.98.3 with the TkAgg backend on Mac OS X. >> >> I will update matplotlib from the site and try again. My attempt to >> use GtkAgg failed presumably because I don't have things set up with >> GTk on my Mac. >> >> best >> Kaushik >> >> Michael Droettboom wrote: >> >>> I'm not able to reproduce this on matplotlib SVN head with the GtkAgg >>> backend. Which version and backend are you using? >>> >>> Mike >>> >>> Kaushik Ghose wrote: >>> >>>> PS. In the code just disregard the line N = 1000  it does nothing. >>>> >>>> Ghose, Kaushik wrote: >>>> >>>> >>>>> Hi John, >>>>> >>>>> OK. I've managed to pare it down to the following pattern: >>>>> >>>>> import pylab >>>>> >>>>> N = 1000 >>>>> x = pylab.zeros(200) >>>>> x[1] = .5 >>>>> x[2:24] = 1.0 >>>>> x[24] = .5 >>>>> x[26] = .5 >>>>> x[27:49] = 1.0 >>>>> x[49] = .5 >>>>> x = pylab.tile(x, 100) >>>>> pylab.plot(x) >>>>> >>>>> >>>>> The above code is sufficient to repeat the glitch (just resize the >>>>> window to >>>>> check this). The halfway values (0.5) are important  if we have a >>>>> straight >>>>> jump the glitch isn't visible. >>>>> >>>>> I'm sorry but I couldn't find path.py under >>>>> >>>>> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/sitepackages/ >>>>> >>>>> >>>>> so I couldn't try it out. (Is it under a different place in mac?) >>>>> >>>>> thanks >>>>> Kaushik >>>>> >>>>> >>>>> >>>>> John Hunter wrote: >>>>> >>>>> >>>>>> On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose >>>>>> <Kaushik_Ghose@...> wrote: >>>>>> >>>>>> >>>>>>> Hi Gang, >>>>>>> >>>>>>> I was plotting some data collected from an ADC and noticed an odd >>>>>>> aliasing >>>>>>> issue. Please see the images on the following site. >>>>>>> >>>>>>> http://assortedexperience.blogspot.com/2008/12/oddaliasingissuewithmatplotlib.html >>>>>>> >>>>>>> >>>>>>> I wonder if there is any way to avoid this kind of aliasing. I >>>>>>> vaguely remember >>>>>>> our old archfoe (MATLAB) handles this gracefully. I have found >>>>>>> matplotlib's >>>>>>> plotting to be superior to MATLAB's in every way (except for 3D) >>>>>>> and it would be >>>>>>> nice if aliasing could be handled gracefully. >>>>>>> >>>>>>> >>>>>> I'm almost certain this is a result of the path simplification logic. >>>>>> Could you upload some sample data and a self contained script so we >>>>>> can test? >>>>>> You can test this by editing sitepackages/path.py and replacing:: >>>>>> >>>>>> self.should_simplify = (len(vertices) >= 128 and >>>>>> (codes is None or np.all(codes <= >>>>>> Path.LINETO))) >>>>>> >>>>>> with:: >>>>>> >>>>>> self.should_simplify = False >>>>>> >>>>>> Michael, perhaps we could override path.should_simplify with an rc or >>>>>> line property? >>>>>> >>>>>> >>>>>> >>>>>>> Also, thanks for the excellent binary packages for Mac! >>>>>>> >>>>>>> >>>>>> Thanks for testing them! >>>>>> >>>>>> >>>>>  >>>>> >>>>> _______________________________________________ >>>>> Matplotlibusers mailing list >>>>> Matplotlibusers@... >>>>> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >>>>> >>>>> >>>>  >>>> >>>> _______________________________________________ >>>> Matplotlibusers mailing list >>>> Matplotlibusers@... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlibusers >>>> >>>> >>>  >>> Michael Droettboom >>> Science Software Branch >>> Operations and Engineering Division >>> Space Telescope Science Institute >>> Operated by AURA for NASA >>> >>> > >  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: John Hunter <jdh2358@gm...>  20081229 15:06:32

On Mon, Dec 29, 2008 at 8:44 AM, Michael Droettboom <mdroe@...> wrote: > This is now fixed in SVN HEAD. > > Two changes were made: > > a) Be more conservative about when segments are simplified based on their > length > > b) Honor the (already existing) path.simplify rcParam in the *Agg backends. I didn't see that we already had the param  we should probably backport b) to honor the param to the branch, no? JDH 
From: Michael Droettboom <mdroe@st...>  20081229 15:12:15

John Hunter wrote: > On Mon, Dec 29, 2008 at 8:44 AM, Michael Droettboom <mdroe@...> wrote: > >> This is now fixed in SVN HEAD. >> >> Two changes were made: >> >> a) Be more conservative about when segments are simplified based on their >> length >> >> b) Honor the (already existing) path.simplify rcParam in the *Agg backends. >> > > I didn't see that we already had the param  we should probably > backport b) to honor the param to the branch, no? > I don't see any harm in (b). The other change (a) is more experimental. I'll go ahead and make this change. Mike  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 