Menu
▾
▴
Re: [matplotlib-devel] Problem with Agg Ellipses
|
From: Michael D. <md...@st...> - 2007-12-11 20:48:01
|
And an actually interesting part of the plot... ;) Michael Droettboom wrote: > Sorry -- correct attachment this time. > > Michael Droettboom wrote: >> I have a working draft of something that may work for this problem on >> the transforms branch. I am happy to backport this to the trunk, but >> that will require some effort, as the implementation relies on many of >> the new geometric utilities on the branch that would also have to be >> brought over. It may be some time until the branch is ready for >> production use, but if you are able to use it to experiment with this >> approach to this specific problem, that would certainly make my life >> easier, so I don't have to do the backporting work more than once. >> >> Attached is a plot comparing the new approach (above) vs. a 750-edge >> polygonal approximation for the ellipses (based directly on James >> Evans' example). Here's a description of what it does: >> >> >> Ellipses are normally drawn using an approximation that uses >> eight cubic bezier splines. The error of this approximation >> is 1.89818e-6, according to this unverified source: >> >> Lancaster, Don. Approximating a Circle or an Ellipse Using >> Four Bezier Cubic Splines. >> >> http://www.tinaja.com/glib/ellipse4.pdf >> >> There is a use case where very large ellipses must be drawn >> with very high accuracy, and it is too expensive to render the >> entire ellipse with enough segments (either splines or line >> segments). Therefore, in the case where either radius of the >> ellipse is large enough that the error of the spline >> approximation will be visible (greater than one pixel offset >> from the ideal), a different technique is used. >> >> In that case, only the visible parts of the ellipse are drawn, >> with each visible arc using a fixed number of spline segments >> (8). The algorithm proceeds as follows: >> >> 1. The points where the ellipse intersects the axes bounding >> box are located. (This is done be performing an inverse >> transformation on the axes bbox such that it is relative to >> the unit circle -- this makes the intersection calculation >> much easier than doing rotated ellipse intersection >> directly). >> >> This uses the "line intersecting a circle" algorithm from: >> >> Vince, John. Geometry for Computer Graphics: Formulae, >> Examples & Proofs. London: Springer-Verlag, 2005. >> >> 2. The angles of each of the intersection points are >> calculated. >> >> 3. Proceeding counterclockwise starting in the positive >> x-direction, each of the visible arc-segments between the >> pairs of vertices are drawn using the bezier arc >> approximation technique implemented in Path.arc(). >> >> >> Cheers, >> Mike >> >> >> Ted Drain wrote: >>> All of these sound like good ideas to me. Just for some history: the >>> original reason we worked w/ John to get an Ellipse primitive in (vs >>> a normal line plot of sampled points) were to: >>> - improve ellipse plotting speeds (we plot a LOT of them at once) >>> - improve post script output >>> >>> Ted >>> >>> At 08:53 AM 12/10/2007, Michael Droettboom wrote: >>>> John Hunter wrote: >>>>> On Dec 10, 2007 10:25 AM, Ted Drain <ted...@jp...> wrote: >>>>> >>>>>> I don't know if the current MPL architecture can support this but it >>>>>> would be nice if it worked that way. We have people making decisions >>>>>> based on what these plots show that affect spacecraft worth hundreds >>>>>> of millions of dollars so it's important that we're plotting >>>> things accurately. >>>>> We can support this, but I think we would do this with an arc class >>>>> rather than an ellipse class, and write a special case class that is >>>>> viewlim aware. >>>> I agree -- I think there are two uses cases for ellipse that are in >>>> conflict here. One is these large ellipses, the other is for things >>>> like scatter plots, where speed and file size is more important than >>>> accuracy. My mind was probably stuck on the latter as I've worked >>>> along >>>> the transforms branch. >>>> >>>>> A simple example of a line that has analogous >>>>> behavior is examples/clippedline.py, which clips the points outside >>>>> the viewport and draws in a different style according to the >>>>> resolution of the viewlim. The reason I think it would be preferable >>>>> to use an arc here is because we won't have to worry about filling the >>>>> thing when we only approximate a section of it. You could feed in a >>>>> 360 degree elliptical arc and then zoom into a portion of it. >>>>> >>>>> With the 8 point ellipse as is, and the addition of an arc class that >>>>> does 4 or 8 point approximation within the zoom limits, should that >>>>> serve your requirements? >>>> As a possible starting point, the transforms branch already has >>>> arc-approximation-by-cubic-bezier-spline code. It determines the >>>> number >>>> of splines to use based on the radians included in the arc, which is >>>> clearly not what we want here. But it should be reasonably >>>> straightforward to make that some fixed number and draw the arc between >>>> the edges of the axes. Or, alternatively, (and maybe this is what John >>>> is suggesting), the arc could be approximated by line segments (with >>>> the >>>> number of segments something like the number of pixels across the >>>> axes). >>>> To my naive mind, that seems more verifiable -- or at least it puts >>>> the responsibility of getting this right all in one place. >>>> >>>> IMHO, these spline approximation tricks are all just with the aim of >>>> pushing curve rendering deeper into the backends for speed and file >>>> size >>>> improvements. But obviously there needs to be a way around it when it >>>> matters. >>>> >>>> Cheers, >>>> Mike >>>> >>>> -- >>>> Michael Droettboom >>>> Science Software Branch >>>> Operations and Engineering Division >>>> Space Telescope Science Institute >>>> Operated by AURA for NASA >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> SF.Net email is sponsored by: >>>> Check out the new SourceForge.net Marketplace. >>>> It's the best place to buy or sell services for >>>> just about anything Open Source. >>>> http://sourceforge.net/services/buy/index.php >>>> _______________________________________________ >>>> Matplotlib-devel mailing list >>>> Mat...@li... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> Ted Drain Jet Propulsion Laboratory ted...@jp... >>> >>> ------------------------------------------------------------------------- >>> >>> SF.Net email is sponsored by: Check out the new SourceForge.net >>> Marketplace. >>> It's the best place to buy or sell services for >>> just about anything Open Source. >>> http://sourceforge.net/services/buy/index.php >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: Check out the new SourceForge.net >> Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
