Re: [matplotlib-devel] Problem with Agg Ellipses

2007-12-21 Thread Michael Droettboom
I have ported this arc stuff to the trunk.  It is in r4783.  Please let 
me know how that works, particularly wrt performance, for you.  Some 
things that are in C on the branch were done in Python on the trunk for 
convenience.

Cheers,
Mike

Michael Droettboom wrote:
> 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
>>> 
>>> 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
>>>

Re: [matplotlib-devel] Problem with Agg Ellipses

2007-12-21 Thread John Hunter
On Dec 21, 2007 9:11 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:

> > 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.

> I have ported this arc stuff to the trunk.  It is in r4783.  Please let
> me know how that works, particularly wrt performance, for you.  Some
> things that are in C on the branch were done in Python on the trunk for
> convenience.

Awesome -- thanks again Michael.  You keep stealing my holiday projects :-)

I added a check to make sure the 'axes' instance was present at draw
time, since patches can be added directly to the figure also, and
noted in the docstring that this is an axes only object.

I also added unit support, which is fairly trivial, and added Arc to
the unit/ellipse_large.py test case and
examples/unit/ellipse_with_units.py

Great work!
JDH

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] Problem with Agg Ellipses

2007-12-21 Thread Ted Drain

Everyone,
I just wanted to say thanks for tackling this problem so 
quickly.  It's great to see that problems can be worked out like this 
and we really appreciate it.


Here is some background on what we're using this for:  The current 
NASA mission to Mars (Phoenix) will be landing at the end of 
May.  They normally view their current trajectory and associated 
uncertainty as a plot of an ellipse projected on a plane that extends 
out from the center of the body (with time to impact the plane being 
another parameter).  The spacecraft has to hit a very narrow entry 
flight path angle corridor at the atmosphere - too steep and it burns 
up, too shallow and it skips out.  When this corridor is projected 
onto the plane mentioned above, it forms a large circle around 
Mars.  So those large circular plots we're making are the safe entry 
corridor that the trajectory needs to hit and the smaller ellipses 
are the possible trajectory entry points and uncertainties.  As you 
can imagine, it's fairly critical to get those ellipses plotted accurately :)


Thanks again,
Ted

At 08:23 AM 12/21/2007, John Hunter wrote:

On Dec 21, 2007 9:11 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:

> > 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.

> I have ported this arc stuff to the trunk.  It is in r4783.  Please let
> me know how that works, particularly wrt performance, for you.  Some
> things that are in C on the branch were done in Python on the trunk for
> convenience.

Awesome -- thanks again Michael.  You keep stealing my holiday projects :-)

I added a check to make sure the 'axes' instance was present at draw
time, since patches can be added directly to the figure also, and
noted in the docstring that this is an axes only object.

I also added unit support, which is fairly trivial, and added Arc to
the unit/ellipse_large.py test case and
examples/unit/ellipse_with_units.py

Great work!
JDH

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] Problem with Agg Ellipses

2007-12-21 Thread Michael Droettboom
Ok -- this goes without saying, but...  I've only tested this with the 
toy examples you guys have sent etc.  Please verify the results on real 
data before relying on it.

Anyway, it's great to have contributed even such a small part to such a 
great undertaking!

Cheers,
Mike

Ted Drain wrote:
> Everyone,
> I just wanted to say thanks for tackling this problem so quickly.  It's 
> great to see that problems can be worked out like this and we really 
> appreciate it.
> 
> Here is some background on what we're using this for:  The current NASA 
> mission to Mars (Phoenix) will be landing at the end of May.  They 
> normally view their current trajectory and associated uncertainty as a 
> plot of an ellipse projected on a plane that extends out from the center 
> of the body (with time to impact the plane being another parameter).  
> The spacecraft has to hit a very narrow entry flight path angle corridor 
> at the atmosphere - too steep and it burns up, too shallow and it skips 
> out.  When this corridor is projected onto the plane mentioned above, it 
> forms a large circle around Mars.  So those large circular plots we're 
> making are the safe entry corridor that the trajectory needs to hit and 
> the smaller ellipses are the possible trajectory entry points and 
> uncertainties.  As you can imagine, it's fairly critical to get those 
> ellipses plotted accurately :)
> 
> Thanks again,
> Ted
> 
> At 08:23 AM 12/21/2007, John Hunter wrote:
>> On Dec 21, 2007 9:11 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>>
>> > > 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.
>>
>> > I have ported this arc stuff to the trunk.  It is in r4783.  Please let
>> > me know how that works, particularly wrt performance, for you.  Some
>> > things that are in C on the branch were done in Python on the trunk for
>> > convenience.
>>
>> Awesome -- thanks again Michael.  You keep stealing my holiday 
>> projects :-)
>>
>> I added a check to make sure the 'axes' instance was present at draw
>> time, since patches can be added directly to the figure also, and
>> noted in the docstring that this is an axes only object.
>>
>> I also added unit support, which is fairly trivial, and added Arc to
>> the unit/ellipse_large.py test case and
>> examples/unit/ellipse_with_units.py
>>
>> Great work!
>> JDH
>>
>> -
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse012070mrt/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/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel