Re: [matplotlib-devel] path simplification can decrease the smoothness of data plots
I've checked this change into SVN so others can test it out. Assuming we don't discover any cases where this is clearly inferior, it should make it into the next major release. Mike Andrew Hawryluk wrote: >> -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 > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- 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
Michael Droettboom writes: > > I've checked this change into SVN so others can test it out. > > Assuming we don't discover any cases where this is clearly inferior, it > should make it into the next major release. > > Mike > Hi, This change looks good- it has the advantage of choosing points that actually lie on the curve, which is better visually, and would seem to be a better solution for publication quality plots. The method for simplifying the paths is quite simple and effective, but a bit crude- there are other algorithms you might look into for simplifying lines: http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm This one is fairly simple to implement and has the advantage that you have some control over the errors- the deviation from your simplified path and the actual path. Also, you might consider to make the path simplification tolerance (perdNorm2) an adjustable parameter in the matplotlibrc file: #src/agg_py_path_iterator.h //if the perp vector is less than some number of (squared) //pixels in size, then merge the current vector if (perpdNorm2 < (1.0 / 9.0)) kind regards, a -- 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
a wrote: > Michael Droettboom writes: > > >> I've checked this change into SVN so others can test it out. >> >> Assuming we don't discover any cases where this is clearly inferior, it >> should make it into the next major release. >> >> Mike >> >> > > Hi, > > This change looks good- it has the advantage of choosing points that actually > lie on the curve, which is better visually, and would seem to be a better > solution for publication quality plots. > > The method for simplifying the paths is quite simple and effective, but a bit > crude- there are other algorithms you might look into for simplifying lines: > > http://en.wikipedia.org/wiki/Ramer-Douglas-Peucker_algorithm > > This one is fairly simple to implement and has the advantage that you have > some > control over the errors- the deviation from your simplified path and the > actual > path. > Thanks for the pointers. The original simplification code was written by John Hunter (I believe), and I don't know if it was designed by him also or is a replication of something published elsewhere. So I take no credit for and have little knowledge of its original goals. However, IMHO the primary purpose of the path simplification in matplotlib is to improve interactive performance (and smaller file size is just an convenient side effect of that), I would hesitate to use an algorithm that is any worse than O(n), since it must be recalculated on every pan or zoom since the simplification is related to *pixels* not data units. Even on modern hardware, it is a constant battle keeping the inner drawing loop fast enough. We could, of course, make the choice of algorithm user-configurable, or use something more precise when using a non-interactive backend, but then we would have two separate code paths to keep in sync and bug free --- not a choice I take lightly. The trick with the present algorithm is to keep the error rate at the subpixel level through the correct selection of perpdNorm. It seems to me that the more advanced simplification algorithm is only necessary when you want to simplify more aggressively than the pixel level. But what hasn't been done is a proper study of the error rate along the simplified path of the current approach vs. other possible approaches. Even this latest change was verified by just looking at the results which seemingly are better on the data I looked at. So I'm mostly speaking from my gut rather than evidence here. > Also, you might consider to make the path simplification tolerance (perdNorm2) > an adjustable parameter in the matplotlibrc file: > > #src/agg_py_path_iterator.h > > //if the perp vector is less than some number of (squared) > //pixels in size, then merge the current vector > if (perpdNorm2 < (1.0 / 9.0)) > That sounds like a good idea. I'll have a look at doing that. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- 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] Unit Converter Interface Issue
All, I have a suggestion for the units.ConversionInterface class. It seems to me that for each method of the ConversionInterface there should be another parameter passed in, the Axis instance that is requesting the conversion/info. Doing so would allow for any custom conversion code to make checks on the Axis, whether it is X/Y, or even make checks on the Axes the Axis is attached to. Additionally this would allow for converters to apply any necessary changes before they are really used (such as DateConverter making sure that the axis bounds are >= 1). Comments/Suggestions? If it is okay, I would like to apply the necessary changes. --James Evans -- 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
Michael Droettboom writes: > > > Thanks for the pointers. > > The original simplification code was written by John Hunter (I believe), > and I don't know if it was designed by him also or is a replication of > something published elsewhere. So I take no credit for and have little > knowledge of its original goals. I'm not sure on everything it does, but it seems to do clipping and removes line segments where the change in slope is less than some limit. There are probably better algorithms out there, but this one works surprisingly well and is fast and simple. I think it should be a requirement that it returns points which are a subset of the original points- with the change you've made it does this, right? > > However, IMHO the primary purpose of the path simplification in > matplotlib is to improve interactive performance (and smaller file size > is just an convenient side effect of that), I would hesitate to use an > algorithm that is any worse than O(n), since it must be recalculated on > every pan or zoom since the simplification is related to *pixels* not > data units. Even on modern hardware, it is a constant battle keeping > the inner drawing loop fast enough. We could, of course, make the > choice of algorithm user-configurable, or use something more precise > when using a non-interactive backend, but then we would have two > separate code paths to keep in sync and bug free --- not a choice I > take lightly. I see your point. I originally encountered a problem when preparing a pdf figure- I had a lot of high resolution data, and with path simplification the resulting pdf looked pretty bad (the lines were jagged). But the advantage was a massive reduction in file size of the pdf. I adjusted perpdNorm2 and got much better results. > > The trick with the present algorithm is to keep the error rate at the > subpixel level through the correct selection of perpdNorm. It seems to > me that the more advanced simplification algorithm is only necessary > when you want to simplify more aggressively than the pixel level. But > what hasn't been done is a proper study of the error rate along the > simplified path of the current approach vs. other possible approaches. > Even this latest change was verified by just looking at the results > which seemingly are better on the data I looked at. So I'm mostly > speaking from my gut rather than evidence here. > > > > #src/agg_py_path_iterator.h > > > > //if the perp vector is less than some number of (squared) > > //pixels in size, then merge the current vector > > if (perpdNorm2 < (1.0 / 9.0)) > > > That sounds like a good idea. I'll have a look at doing that. > Right, perhaps the best thing to do is make the tolerance parameter adjustable, so it can be reduced to speed up drawing in the interactive backends, but it can also be easily bumped up for extra resolution in the non-interactive backends like pdf/ps. > Mike > a -- 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
