Problem with Agg Ellipses

Development matplotlib-devel
1

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 <mdroe@...31...>
Subject: Re: [matplotlib-devel] Problem with Agg Ellipses
To: Ted Drain <ted.drain@...179...>
Cc: matplotlib development list
  <matplotlib-devel@lists.sourceforge.net>
Message-ID: <475EF771.3090805@...31...>
Content-Type: text/plain; charset="iso-8859-1"

And an actually interesting part of the plot... :wink:

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.drain@...179...> 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
>>>> matplotlib-devel List Signup and Options
>>>
>>> Ted Drain Jet Propulsion Laboratory ted.drain@...179...
>>>
>>> -------------------------------------------------------------------------
>>>
>>> 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
>>> matplotlib-devel List Signup and Options
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>> matplotlib-devel List Signup and Options
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> matplotlib-devel List Signup and Options

--
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
matplotlib-devel List Signup and Options

End of Matplotlib-devel Digest, Vol 19, Issue 16
************************************************

2

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 <mdroe@...31...>
Subject: Re: [matplotlib-devel] Problem with Agg Ellipses
To: Ted Drain <ted.drain@...179...>
Cc: matplotlib development list
  <matplotlib-devel@lists.sourceforge.net>
Message-ID: <475EF771.3090805@...31...>
Content-Type: text/plain; charset="iso-8859-1"

And an actually interesting part of the plot... :wink:

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.drain@...179...> 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
matplotlib-devel List Signup and Options

Ted Drain Jet Propulsion Laboratory ted.drain@...179...

-------------------------------------------------------------------------

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
matplotlib-devel List Signup and Options

------------------------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options

------------------------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options

--
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
matplotlib-devel List Signup and Options

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
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

3

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 <mdroe@...31...>
Subject: Re: [matplotlib-devel] Problem with Agg Ellipses
To: Ted Drain <ted.drain@...179...>
Cc: matplotlib development list
  <matplotlib-devel@lists.sourceforge.net>
Message-ID: <475EF771.3090805@...31...>
Content-Type: text/plain; charset="iso-8859-1"

And an actually interesting part of the plot... :wink:

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.drain@...179...> 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
matplotlib-devel List Signup and Options

Ted Drain Jet Propulsion Laboratory ted.drain@...179...

-------------------------------------------------------------------------

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
matplotlib-devel List Signup and Options

------------------------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options

------------------------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
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
matplotlib-devel List Signup and Options

--
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
matplotlib-devel List Signup and Options

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
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

4

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

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

···

On Dec 21, 2007 9:11 AM, Michael Droettboom <mdroe@...31...> 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.

5

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 :slight_smile:

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/vse0120000070mrt/direct/01/

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net


https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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 :slight_smile:

Thanks again,

Ted

···

On Dec 21, 2007 9:11 AM, Michael > Droettboom <mdroe@…31…> wrote:

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

6

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 :slight_smile:

Thanks again,
Ted

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

On Dec 21, 2007 9:11 AM, Michael Droettboom <mdroe@...31...> 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 :slight_smile:

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/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA