[matplotlib-devel] suggestion for the interpolation in imshow()
The interpolation algorithm used in imshow() can produce spurious results, as has been noted before: http://article.gmane.org/gmane.comp.python.matplotlib.general/12062 This happens because the data is converted to RGB before the interpolation/resampling, rather than after. How hard would it be to reverse this so that the data array is first interpolated & resampled and then converted by cmap to RGB? Andrew Hawryluk - 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-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] suggestion for the interpolation in imshow()
> Eric Firing wrote: > > Andrew Hawryluk wrote: >> The interpolation algorithm used in imshow() can produce spurious >> results, as has been noted before: >> >> _http://article.gmane.org/gmane.comp.python.matplotlib.general/12062_ >> >> This happens because the data is converted to RGB before the >> interpolation/resampling, rather than after. How hard would it be to >> reverse this so that the data array is first interpolated & resampled >> and then converted by cmap to RGB? > > To me, it looks very hard. The color mapping is done first, in python, and not repeated with > every draw. The interpolation is done by agg at rendering time. Logically, I don't know any > reason why agg shouldn't do what you suggest: interpolate the scalar field and then convert > to rgb. > Maybe agg can do it this way. If so, it would still take quite a bit of work by someone > comfortable with agg (i.e., not me) to make the change. > > Eric Ah, that is certainly more difficult that what I would be prepared to attempt, which is unfortunate because it would greatly improve the output and reduce the interpolation's computation by a factor of three (RGB). Until someone feels up to the challenge, I will just add a manual interpolation step when necessary for my data. e.g.: import matplotlib.pyplot as p import numpy as n import scipy.ndimage a = n.random.normal(size=(10,10)) p.imshow(a,interpolation='nearest') # the actual data p.figure() p.imshow(a,interpolation='bicubic') # an AGG interpolation of the RGB values b = scipy.ndimage.zoom(a,25)[:-24,:-24] p.figure() p.imshow(b) # the data interpolated at 25x magnification with a cubic spline Thanks for the information, Andrew - 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-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] path simplification can decrease the smoothness of data plots
I'm really excited about the new path simplification option for vector
output formats. I tried it the first time yesterday and reduced a PDF
from 231 kB to 47 kB. Thanks very much for providing this feature!
However, I have noticed that the simplified paths often look more jagged
than the original, at least for my data. I can recreate the effect with
the following:
[start]
import numpy as np
import matplotlib.pyplot as plt
x = np.arange(-3,3,0.001)
y = np.exp(-x**2) + np.random.normal(scale=0.001,size=x.size)
plt.plot(x,y)
plt.savefig('test.png')
plt.savefig('test.pdf')
[end]
A sample output is attached, and close inspection shows that the PNG is
a smooth curve with a small amount of noise while the PDF version has
very noticeable changes in direction from one line segment to the next.
<> <>
The simplification algorithm (agg_py_path_iterator.h) does the
following:
If line2 is nearly parallel to line1, add the parallel component to
the length of line1, leaving it direction unchanged
which results in a new data point, not contained in the original data.
Line1 will continue to be lengthened until it has deviated from the data
curve enough that the next true data point is considered non-parallel.
The cycle then continues. The result is a line that wanders around the
data curve, and only the first point is guaranteed to have existed in
the original data set.
Instead, could the simplification algorithm do:
If line2 is nearly parallel to line1, combine them by removing the
common point, leaving a single line where both end points existed in the
original data
Thanks again,
Andrew Hawryluk
<>
test.pdf
Description: test.pdf
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots
> -Original Message- > From: Michael Droettboom [mailto:md...@stsci.edu] > Sent: 16 Jan 2009 1:31 PM > To: Andrew Hawryluk > Cc: matplotlib-devel@lists.sourceforge.net > Subject: Re: [matplotlib-devel] path simplification can decrease the > smoothness of data plots > > Michael Droettboom wrote: ... > I've attached a patch that will only include points from the original > data in the simplified path. I hesitate to commit it to SVN, as these > things are very hard to get right -- and just because it appears to > work better on this data doesn't mean it doesn't create a regression on > something else... ;) That said, it would be nice to confirm that this > solution works, because it has the added benefit of being a little > simpler computationally. Be sure to blitz your build directory when > testing the patch -- distutils won't pick it up as a dependency. > > I've attached two PDFs -- one with the original (current trunk) > behavior, and one with the new behavior. I plotted the unsimplified > plot in thick blue behind the simplified plot in green, so you can see > how much deviation there is between the original data and the > simplified line (you'll want to zoom way in with your PDF viewer to see > it.) > > I've also included a new version of your test script which detects > "new" > data values in the simplified path, and also seeds the random number > generator so that results are comparable. I also set the > solid_joinstyle to "round", as it makes the wiggliness less pronounced. > (There was another thread on this list recently about making that the > default setting). > > Cheers, > Mike > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA Thanks for looking into this! The new plot is much improved, and the simplified calculations are a pleasant surprise. I was also testing the previous algorithm with solid_joinstyle set to "round" as it is the default in my matplotlibrc. I am probably not able to build your patch here, unless building matplotlib from source on Windows is easier than I anticipate. May I send you some data off the list for you to test? Regards, Andrew NOVA Chemicals Research & Technology Centre Calgary, Canada -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] cannot use some fonts on pdf, ps, eps backends
When I use Arial Unicode MS within matplotlib, it cannot save to any
PostScript-based formats (pdf, eps, ps). Apparently, the font has no
glyph names:
Traceback (most recent call last):
File "G:\Chem2009\GK6 Fan Dynamics\plotFanCurve.py", line 31, in
p.savefig('memo/figures/normalizedFanCurve.pdf')
File "C:\Python25\lib\site-packages\matplotlib\pyplot.py", line 345,
in savefig
return fig.savefig(*args, **kwargs)
File "C:\Python25\lib\site-packages\matplotlib\figure.py", line 990,
in savefig
self.canvas.print_figure(*args, **kwargs)
File "C:\Python25\lib\site-packages\matplotlib\backend_bases.py", line
1419, in print_figure
**kwargs)
File "C:\Python25\lib\site-packages\matplotlib\backend_bases.py", line
1313, in print_pdf
return pdf.print_pdf(*args, **kwargs)
File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1886, in print_pdf
self.figure.draw(renderer)
File "C:\Python25\lib\site-packages\matplotlib\figure.py", line 772,
in draw
for a in self.axes: a.draw(renderer)
File "C:\Python25\lib\site-packages\matplotlib\axes.py", line 1601, in
draw
a.draw(renderer)
File "C:\Python25\lib\site-packages\matplotlib\axis.py", line 725, in
draw
self.label.draw(renderer)
File "C:\Python25\lib\site-packages\matplotlib\text.py", line 502, in
draw
ismath=ismath)
File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1573, in draw_text
return draw_text_woven(chunks)
File
"C:\Python25\lib\site-packages\matplotlib\backends\backend_pdf.py", line
1543, in draw_text_woven
glyph_name = font.get_glyph_name(gind)
RuntimeError: Face has no glyph names
I can reproduce this error with several fonts on my system.
(Coincidentally, all the fonts that have a full set of superscript
characters, which I could really use for my plots.) I know that these
fonts can be included in PDFs, because I can do it in other programs. I
also checked the archives and the bug list for clues as to what may be
going on, but came up empty. Any idea what the problem might be? Thanks!
Andrew
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] cannot use some fonts on pdf, ps, eps backends
> -Original Message- > From: Jouni K. Seppänen [mailto:j...@iki.fi] > Sent: 6 Apr 2009 1:20 PM > To: matplotlib-devel@lists.sourceforge.net > Subject: Re: [matplotlib-devel] cannot use some fonts on pdf, ps,eps > backends > > "Andrew Hawryluk" writes: > > > When I use Arial Unicode MS within matplotlib, it cannot save to any > > PostScript-based formats (pdf, eps, ps). Apparently, the font has no > > glyph names: > [...] > > glyph_name = font.get_glyph_name(gind) > > RuntimeError: Face has no glyph names > What version of Freetype do you have - does updating it help? The check > for glyph names is just a call to a Freetype macro I am using the most recent windows binary (0.98.5.2), so I'm guessing that my Freetype library came bundled inside it. > Does it help if you set ps.fonttype and pdf.fonttype to 42 in > matplotlibrc? Yes, that works very well, thanks! However, it now embeds the entire font rather than a subset. This results in a PDF of 14.4 MB with this font. I ran it through ghostscript to get a PDF of 24.2 kB with subsetting, but I'm wondering if I can get subsetting of type 42 fonts directly from matplotlib? Thanks again, Andrew -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] performance (speed) of logarithmic plots
I've observed a significant difference in the time required by different plotting functions. With a plot of 5000 random data points (all positive, non-zero), plt.semilogx takes 3.5 times as long as plt.plot. (Data for the case of saving to PDF, ratio changes to about 3.1 for PNG on my machine.) I used cProfile (script attached) and found several significant differences between the profiles of each plotting command. On my first analysis, it appears that most of the difference is due to increased use of mathtext in semilogx: == Plotting command == cumtime (s) plotsemilogx semilogy loglog == total running time 0.618 2.192 0.953 1.362 axis.py:181(draw) 0.118 1.500 0.412 0.569 text.py:504(draw) 0.056 1.353 0.290 0.287 mathtext.py:2765(__init__) 0.000 1.018 0.104 0.103 mathtext.py:2772(parse) --- 1.294 0.143 0.254 pyparsing.py:1018(parseString) --- 0.215 0.216 0.221 pyparsing.py:3129(oneOf)--- 0.991 --- --- pyparsing.py:3147() --- 0.358 --- --- lines.py:918(_draw_solid) 0.243 0.358 0.234 0.352 = It seems that semilogx could be made as fast as semilogy since they have to do the same amount of work, but I'm not sure where the differences lie. Can anyone suggest where I should look first? Much thanks, Andrew Hawryluk matplotlib.__version__ = '0.99.1' Windows XP Professional Version 2002, Service Pack 3 Intel Pentium 4 CPU 3.00 GHz, 2.99 GHz, 0.99 GB of RAM semilogPerformance.py Description: semilogPerformance.py -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] performance (speed) of logarithmic plots
> Hello, > How did you get the cumtime listing? The output of the run doesn't produce a > cumulative sum table as you showed here. > Gökhan No, it doesn't. The output of the run is four huge cProfile listings, one for each plotting command tested. I manually searched the data for long cumtime's that differed between the plots and typed the table myself. I have also confirmed the speed differences on matplotlib 0.99.0 under Ubuntu 9.10: plot 0.629 CPU seconds semilogx 3.430 CPU seconds semilogy 1.044 CPU seconds loglog1.479 CPU seconds I'll try to figure out why semilogx uses so much more mathtext than semilogy, but if anyone familiar with the code is curious enough to look into it they will probably beat me to the answer. Andrew -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] hist doesn't work with 2D arrays
Hopefully this isn't old news for you. Since the 0.98 release, the histogram plot doesn't work properly with 2D arrays: it is quite slow and the output is wrong. Passing a flattened array produces the quick, correct output that we are accustomed to. Here is the test code I ran, and the attached image shows the output compared with the previous version. import numpy as n import matplotlib.pyplot as p a = n.random.normal(size=1) a = a.reshape((100,100)) # make a 2D array of normally-distributed random numbers p.hist(a) Thanks for your work on matplotlib! Andrew Hawryluk Calgary, Canada <> <>- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hist doesn't work with 2D arrays
Ah - that makes sense. I guess I didn't catch that change in the release notes. Thanks again! -Original Message- From: Manuel Metz [mailto:[EMAIL PROTECTED] Sent: 7 Jul 2008 11:49 AM To: matplotlib-devel@lists.sourceforge.net Cc: Andrew Hawryluk Subject: Re: [matplotlib-devel] hist doesn't work with 2D arrays Andrew Hawryluk wrote: > Hopefully this isn't old news for you. Since the 0.98 release, the histogram > plot doesn't work properly with 2D arrays: it is quite slow and the output is > wrong. Passing a flattened array produces the quick, correct output that we > are accustomed to. Here is the test code I ran, and the attached image shows > the output compared with the previous version. > > import numpy as n > import matplotlib.pyplot as p > > a = n.random.normal(size=1) > a = a.reshape((100,100)) # make a 2D array of normally-distributed random > numbers > p.hist(a) > > > Thanks for your work on matplotlib! Hi Andrew, 2D arrays are now treated differently. An (N,M) 2D array is interpreted as M data-sets with N elements each, e.g. a = n.random.normal(size=1) a = a.reshape((1000,10)) is interpreted as 10 data-sets with 1000 elements each. See histogram_demo_extended.py in examples/pylab_examples. To reproduce the old behaviour you should use pylab.hist(a.flat). Manuel > Andrew Hawryluk > Calgary, Canada > <> > > > > > > > > - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > > > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
