Porting this back to the trunk is non-trivial -- but I know John would like to do it, so I think it will happen once one of us has time.
As an aside, the unit stuff *should* be working on the branch. Can you send me a minimal example that shows it failing? Cheers, Mike James Evans wrote: > I have taken the transforms branch and played with it a bit and my super > simple ellipse test cases appeared to be working great. I > couldn't run our more intensive tests since they use unitized data and I was > getting errors that looked like the transforms branch > wasn't completely handling unitized data properly. It would be great if we > could see this fix in the main branch, then we can make > use of it right away without having to wait for the transforms branch to be > completed. > > --James Evans > > >> Date: Tue, 11 Dec 2007 15:47:45 -0500 >> From: Michael Droettboom <[EMAIL PROTECTED]> >> Subject: Re: [matplotlib-devel] Problem with Agg Ellipses >> To: Ted Drain <[EMAIL PROTECTED]> >> Cc: matplotlib development list >> <matplotlib-devel@lists.sourceforge.net> >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> 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 <[EMAIL PROTECTED]> 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 >>>>>> Matplotlib-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>> Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] >>>>> >>>>> ------------------------------------------------------------------------- >>>>> >>>>> 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 >>>>> Matplotlib-devel@lists.sourceforge.net >>>>> 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 >>>> Matplotlib-devel@lists.sourceforge.net >>>> 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 >>> Matplotlib-devel@lists.sourceforge.net >>> 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 >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: ellipse.png >> Type: image/png >> Size: 49913 bytes >> Desc: not available >> >> ------------------------------ >> >> ------------------------------------------------------------------------- >> 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 >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> End of Matplotlib-devel Digest, Vol 19, Issue 16 >> ************************************************ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
