transform_angles

Hi,

I just wanted to send a note saying that I committed an additional
method to the Transforms class that transforms angles. The basic idea
is to transform an angle at a point to a new angle at the corresponding
point in the transformed coordinate system. The included method is
generic and should work well for almost any transform provided that the
spatial scale isn't too small or too large. Much faster algorithms that
would work regardless of spatial scale can be found for particular
transforms, particularly affine transforms, but I haven't added these
yet.

I also added an example script that shows how to use this method to plot
text rotated so that it aligns with a line in a figure
( text_rotation_relative_to_line.py ).

I initially intended to use this method to give text objects the option
to be rotated with respect to the plot coordinate system (as opposed to
the screen coordinate system), but I haven't gotten around to finishing
this yet.

Cheers,
David

···

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Darn clogged e-mail queue! :wink:

I see you've already addressed my question...

Cheers,
Mike

David Kaplan wrote:

···

Hi,

I just wanted to send a note saying that I committed an additional
method to the Transforms class that transforms angles. The basic idea
is to transform an angle at a point to a new angle at the corresponding
point in the transformed coordinate system. The included method is
generic and should work well for almost any transform provided that the
spatial scale isn't too small or too large. Much faster algorithms that
would work regardless of spatial scale can be found for particular
transforms, particularly affine transforms, but I haven't added these
yet.

I also added an example script that shows how to use this method to plot
text rotated so that it aligns with a line in a figure
( text_rotation_relative_to_line.py ).

I initially intended to use this method to give text objects the option
to be rotated with respect to the plot coordinate system (as opposed to
the screen coordinate system), but I haven't gotten around to finishing
this yet.

Cheers,
David

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

Hi,

Actually your question is a good one. One of the reasons I never
finished adding an option to text objects to rotate with respect to the
plot (is this the correct terminology?), not the screen, is that I
wasn't sure of the best way to implement this without making it
hopelessly confusing for the user.

One way is to add a boolean that tells the text object whether or not
the angle is with respect to screen coordinates. In this case,
text_obj.get_rotation() would return the angle in whichever coordinate
system is the active one based on the boolean, unless an option to
get_rotation is specified that would force the angle to the screen
coordinate system (this option would then be used by show methods to
assure they get the correct angle for plotting on the screen).
Similarly, set_rotation would set the angle in the active system. The
disadvantage of this approach is that it can be pretty confusing -
unless you consult the boolean, you don't know what your angle is
measured relative to.

Another approach would be to add a ._rotationPlot variable, as well
as .get_rotationPlot and .set_rotationPlot text-object methods. In this
case, using set_rotation would set the "active" angle to be the screen
angle, while using set_rotationPlot would set the "active" angle to be
the plot angle. The non-active angle would be set to None and show
calls would test for whether or not ._rotation is none, in which case
the screen angle would be calculated from the transform. In this case,
get_rotation and get_rotationPlot would return angles in the respective
system, regardless of which one is "active".

What structure would people prefer?

Another reason I never finished this is that I got confused by some of
the code - there was talk of unitful and unitless rotations and
coordinates. Also, I wasn't sure what to do with objects that inherit
the text object class - namely, text with a dash. It didn't seem it was
worth adding this non-screen rotation functionality to these objects.

If anyone can point me in the right direction on these points, I will
try to finish a patch for this functionality.

Cheers,
David

···

On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote:

Darn clogged e-mail queue! :wink:

I see you've already addressed my question...

Cheers,
Mike

David Kaplan wrote:
> Hi,
>
> I just wanted to send a note saying that I committed an additional
> method to the Transforms class that transforms angles. The basic idea
> is to transform an angle at a point to a new angle at the corresponding
> point in the transformed coordinate system. The included method is
> generic and should work well for almost any transform provided that the
> spatial scale isn't too small or too large. Much faster algorithms that
> would work regardless of spatial scale can be found for particular
> transforms, particularly affine transforms, but I haven't added these
> yet.
>
> I also added an example script that shows how to use this method to plot
> text rotated so that it aligns with a line in a figure
> ( text_rotation_relative_to_line.py ).
>
> I initially intended to use this method to give text objects the option
> to be rotated with respect to the plot coordinate system (as opposed to
> the screen coordinate system), but I haven't gotten around to finishing
> this yet.
>
> Cheers,
> David
>
>
>

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

David Kaplan wrote:

Hi,

Actually your question is a good one. One of the reasons I never
finished adding an option to text objects to rotate with respect to the
plot (is this the correct terminology?), not the screen, is that I
wasn't sure of the best way to implement this without making it
hopelessly confusing for the user.

One way is to add a boolean that tells the text object whether or not
the angle is with respect to screen coordinates. In this case,
text_obj.get_rotation() would return the angle in whichever coordinate
system is the active one based on the boolean, unless an option to
get_rotation is specified that would force the angle to the screen
coordinate system (this option would then be used by show methods to
assure they get the correct angle for plotting on the screen).
Similarly, set_rotation would set the angle in the active system. The
disadvantage of this approach is that it can be pretty confusing -
unless you consult the boolean, you don't know what your angle is
measured relative to.

Another approach would be to add a ._rotationPlot variable, as well
as .get_rotationPlot and .set_rotationPlot text-object methods. In this
case, using set_rotation would set the "active" angle to be the screen
angle, while using set_rotationPlot would set the "active" angle to be
the plot angle. The non-active angle would be set to None and show
calls would test for whether or not ._rotation is none, in which case
the screen angle would be calculated from the transform. In this case,
get_rotation and get_rotationPlot would return angles in the respective
system, regardless of which one is "active".

What structure would people prefer?
  

I think the latter choice presents less confusion, particularly after hearing your arguments. It should probably be rotation_plot, just to be consistent with other getters/setters. There should probably also be a check and warning for setting rotation_plot for figure text, where it doesn't make sense, and fall back to the identity transform.

Another reason I never finished this is that I got confused by some of
the code - there was talk of unitful and unitless rotations and
coordinates.

Hopefully someone else has some guidance on unit-related issues. I still don't have my head around that stuff.

Also, I wasn't sure what to do with objects that inherit
the text object class - namely, text with a dash. It didn't seem it was
worth adding this non-screen rotation functionality to these objects.
  

What is the argument against? It seems like this would be straightforward (at least from the outside). But I'm probably missing something.

If anyone can point me in the right direction on these points, I will
try to finish a patch for this functionality.
  

Thanks.

Mike

···

Cheers,
David

On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote:
  

Darn clogged e-mail queue! :wink:

I see you've already addressed my question...

Cheers,
Mike

David Kaplan wrote:
    

Hi,

I just wanted to send a note saying that I committed an additional
method to the Transforms class that transforms angles. The basic idea
is to transform an angle at a point to a new angle at the corresponding
point in the transformed coordinate system. The included method is
generic and should work well for almost any transform provided that the
spatial scale isn't too small or too large. Much faster algorithms that
would work regardless of spatial scale can be found for particular
transforms, particularly affine transforms, but I haven't added these
yet.

I also added an example script that shows how to use this method to plot
text rotated so that it aligns with a line in a figure
( text_rotation_relative_to_line.py ).

I initially intended to use this method to give text objects the option
to be rotated with respect to the plot coordinate system (as opposed to
the screen coordinate system), but I haven't gotten around to finishing
this yet.

Cheers,
David

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

From: Michael Droettboom [mailto:mdroe@…31…]
Sent: Wednesday, November 05, 2008 11:59

David Kaplan wrote:
> Hi,
>
> Actually your question is a good one. One of the reasons I never
> finished adding an option to text objects to rotate with respect to the
> plot (is this the correct terminology?), not the screen, is that I
> wasn't sure of the best way to implement this without making it
> hopelessly confusing for the user.
>
> One way is to add a boolean that tells the text object whether or not
> the angle is with respect to screen coordinates. In this case,
> text_obj.get_rotation() would return the angle in whichever coordinate
> system is the active one based on the boolean, unless an option to
> get_rotation is specified that would force the angle to the screen
> coordinate system (this option would then be used by show methods to
> assure they get the correct angle for plotting on the screen).
> Similarly, set_rotation would set the angle in the active system. The
> disadvantage of this approach is that it can be pretty confusing -
> unless you consult the boolean, you don't know what your angle is
> measured relative to.
>
> Another approach would be to add a ._rotationPlot variable, as well
> as .get_rotationPlot and .set_rotationPlot text-object methods. In this
> case, using set_rotation would set the "active" angle to be the screen
> angle, while using set_rotationPlot would set the "active" angle to be
> the plot angle. The non-active angle would be set to None and show
> calls would test for whether or not ._rotation is none, in which case
> the screen angle would be calculated from the transform. In this case,
> get_rotation and get_rotationPlot would return angles in the respective
> system, regardless of which one is "active".
>
> What structure would people prefer?
>
I think the latter choice presents less confusion, particularly after
hearing your arguments. It should probably be rotation_plot, just to be
consistent with other getters/setters. There should probably also be a
check and warning for setting rotation_plot for figure text, where it
doesn't make sense, and fall back to the identity transform.

Beyond the two options of the screen coordinates and the data coordinates as the references, I
believe it would be useful to allow other coordinate systems. If I wanted to diagonally
watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it would be convenient to
specify a rotation of +/- 45 degrees relative to the normalized (0-1) figure coordinates. The
watermark would lie along the diagonal regardless of the aspect ratio. Likewise, to watermark
only a subplot, one might use the normalized axes coordinates. It seems especially convenient
if users could accomplish that by passing to the text object one of the predefined transforms --
like ax.transData, fig.transFigure, or ax.transAxes -- to specify the coordinate system for the
rotation.

Would it be possible to specify the reference system and rotation angle in a composite transform
using transform machinery such as rotate_deg or rotate_deg_around?

> Another reason I never finished this is that I got confused by some of
> the code - there was talk of unitful and unitless rotations and
> coordinates.
Hopefully someone else has some guidance on unit-related issues. I
still don't have my head around that stuff.
> Also, I wasn't sure what to do with objects that inherit
> the text object class - namely, text with a dash. It didn't seem it was
> worth adding this non-screen rotation functionality to these objects.
>
What is the argument against? It seems like this would be
straightforward (at least from the outside). But I'm probably missing
something.
> If anyone can point me in the right direction on these points, I will
> try to finish a patch for this functionality.
>
Thanks.

Mike
> Cheers,
> David
>
>
>> Darn clogged e-mail queue! :wink:
>>
>> I see you've already addressed my question...
>>
>> Cheers,
>> Mike
>>
>> David Kaplan wrote:
>>
>>> Hi,
>>>
>>> I just wanted to send a note saying that I committed an additional
>>> method to the Transforms class that transforms angles. The basic idea
>>> is to transform an angle at a point to a new angle at the corresponding
>>> point in the transformed coordinate system. The included method is
>>> generic and should work well for almost any transform provided that the
>>> spatial scale isn't too small or too large. Much faster algorithms that
>>> would work regardless of spatial scale can be found for particular
>>> transforms, particularly affine transforms, but I haven't added these
>>> yet.
>>>
>>> I also added an example script that shows how to use this method to plot
>>> text rotated so that it aligns with a line in a figure
>>> ( text_rotation_relative_to_line.py ).
>>>
>>> I initially intended to use this method to give text objects the option
>>> to be rotated with respect to the plot coordinate system (as opposed to
>>> the screen coordinate system), but I haven't gotten around to finishing
>>> this yet.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>
>>>

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

Stan

···

> On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote:

Hi,

What is the argument against? It seems like this would be
straightforward (at least from the outside). But I'm probably
missing
something.

More work for diminishing interest.... Perhaps I am incorrect, but I
think this object is only used for legends and axes labels, which
probably wouldn't use this feature.

If I remember correctly, there was also the problem that the dash had
its own rotation angle, which would require a whole other set of
corresponding variables and methods to select the coordinate system for
the dash....

I think I saw this and just decided to raise not implemented warnings on
attempts to set non-screen coordinate system rotations.

Is there a strong desire for adding this feature to text with dash?

Cheers,
David

···

On Wed, 2008-11-05 at 11:58 -0500, Michael Droettboom wrote:

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi,

Beyond the two options of the screen coordinates and the data
coordinates as the references, I
believe it would be useful to allow other coordinate systems. If I
wanted to diagonally
watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it
would be convenient to
specify a rotation of +/- 45 degrees relative to the normalized (0-1)
figure coordinates. The
watermark would lie along the diagonal regardless of the aspect ratio.
Likewise, to watermark
only a subplot, one might use the normalized axes coordinates. It
seems especially convenient
if users could accomplish that by passing to the text object one of
the predefined transforms --
like ax.transData, fig.transFigure, or ax.transAxes -- to specify the
coordinate system for the
rotation.

Would it be possible to specify the reference system and rotation
angle in a composite transform
using transform machinery such as rotate_deg or rotate_deg_around?

This is an interesting suggestion, but seems like it is (a) a bit out of
my league and (b) like it would bring up other issues, such as which
coordinate system to use for interpreting the location given to the text
function for the text object.

The standard way this problem has been dealt with is to create an
invisible axes that covers your entire plot and add a text object to
that axes. Can this method do the trick for you?

Cheers,
David

···

On Wed, 2008-11-05 at 13:28 -0500, Stan West wrote:

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

David Kaplan wrote:

Hi,

What is the argument against? It seems like this would be straightforward (at least from the outside). But I'm probably
missing something.
    
More work for diminishing interest.... Perhaps I am incorrect, but I
think this object is only used for legends and axes labels, which
probably wouldn't use this feature.

If I remember correctly, there was also the problem that the dash had
its own rotation angle, which would require a whole other set of
corresponding variables and methods to select the coordinate system for
the dash....

I think I saw this and just decided to raise not implemented warnings on
attempts to set non-screen coordinate system rotations.

Is there a strong desire for adding this feature to text with dash?
  

Thanks. I see the complications now. I agree -- let's not worry about TextWithDash for now, except for possibly warning or throwing when trying to use this new feature with a TextWithDash.

Cheers,
Mike

···

On Wed, 2008-11-05 at 11:58 -0500, Michael Droettboom wrote:

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