STC position angles

Steve Allen sla at ucolick.org
Tue Jun 21 11:23:37 PDT 2005


On Tue 2005-06-21T09:02:54 +0100, David Berry hath writ:
> can
> you not meaningfully choose to say that the distance between A(3,5) and
> A(4,7) is sqrt( (3-4)**2 + (5-7)**2 ) pixels, and that the two axes are
> orthogonal?

You can choose to say that, but then you may display it, and nothing
requires that your display have square pixels.  Charles Poynton of Sun
Microsystems lobbied hard to require square pixels in the high
definition video standards.  In the end I don't know whether he
succeeded, but I think he did not.

> Do we need a justification? Can we not say it's a *convention* to describe
> pixel coordinates as flat cartesian axes?

I would be a lot more comfortable if the document contained explicitly
that along with a bunch of caveats regarding the inapplicability of
the concept of angle in some circumstances.

> I agree that your suggested scheme would be far less susceptible to
> mis-interpretation, but of course a lot of software would probably
> immediately turn it back into an angle!

That is because most programmers haven't spent enough time
in non-Euclidean spaces.  If they had, they would shy away from
some of the inappropriate assumptions.

> It depends on what is meant by that phrase "have a clearly-defined
> Euclidean metric". I would say that pixel coordinates can, by convention,
> be described using a Euclidean metric. Is it not just a case of
> specifying the convention being used? Such as, if the STC position
> angle reference is "X" then a position angle of theta defines a curve
> in the (x,y) coordinate system which, for points very close to the origin,
> takes the form
>
>    y = x.tan( theta )
>
> and if the reference is Y then
>
>    y = x/tan( theta )

In cases where the array or table represents phase space, or has a
Minkowski metric, that angle has extremely little meaning.
Indeed, in a Minkowski space you really want to be using sinh, cosh,
and tanh, and you need the metric to define the speed of light.
In such cases it is far better to express an ellipse or vector as a
covariance matrix or coordinate pair.

--
Steve Allen                 <sla at ucolick.org>                   WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165       Lat  +36.99858
University of California    Voice: +1 831 459 3046              Lng -122.06014
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/        Hgt +250 m



More information about the dm mailing list