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://assorted-experience.blogspot.com/2008/12/odd-aliasing-issue-with-matplotlib.html
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember our old arch-foe (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
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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
···
On Sat, Dec 27, 2008 at 10:29 AM, Kaushik Ghose <Kaushik_Ghose@...2126...> 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 half-way 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/site-packages/
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@...2126...> 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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
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 half-way 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/site-packages/
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@...2126...> 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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
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 half-way 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/site-packages/
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@...2126...> 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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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 half-way 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/site-packages/
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@...2126...> 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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
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 half-way 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/site-packages/
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@...2126...> 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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
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
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/site-packages/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 half-way 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/site-packages/
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@...2126...> 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.
Odd aliasing issue with matplotlib
I wonder if there is any way to avoid this kind of aliasing. I vaguely remember
our old arch-foe (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 site-packages/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!
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
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
I didn't see that we already had the param -- we should probably
backport b) to honor the param to the branch, no?
JDH
···
On Mon, Dec 29, 2008 at 8:44 AM, Michael Droettboom <mdroe@...86...> 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.