[TRANSFORM] What is a "frame"?

[David Berry]

Brian

> > The idea of a "Frame" is that it provides all information needed to
> > interpret a set of numerical values describing a position in some
> > corresponding coordinate system - this includes units. Not sure I'm
> > understanding you fully here.
> > [snip]
>
> 	Ah, then there is an additional difference. I understood "frame" to
> 	be a set of values (not necessarily for a position) that have associated
> 	units. So my definition is more expansive. Which raises my question:
> 	Why limit to just positional transforms?

Sorry - my poor choice of words. I'm using the word "position" is in its
most general sense, not just referring to "spatial position". If you
have a plot of "number of sheep" on the Y axis against "farm size" on the
X axis, then a resulting (X,Y) pair would be a "position" in my sense of
the word (i.e. a position within the coordinate space covered by these two
axes). So in this sense, values for wavelength, frequency, flux, time,
etc, are all "positions" within some corresponding Frame.

But note, a Frame does not itself encapsulate a set of numerical axis
values, it just provides a description of the axis. It is the job of a
higher level structure (like a Quantity) to associate a Frame with a set
of numerical axis values.


> > None-the-less, it would obviously be a useful thing to be able to do. To
> > write a such a method may require extra meta-data in the [UNITS] component.
> > The [UNITS] component would describe pixel *value* in the same way
> > that [WCS] describes pixel *position* (i.e. each component would be a
> > "FrameSet" - a collection of coordinate Frames connected together by
> > Mappings):
> >
> >
> >      [UNITS]                               [WCS]
> >     =========                             =======
> >
> >    PIXEL_VALUE                          PIXEL_INDEX
> >         |                                    |
> >         |                                    |
> >         v                                    v
> >       FLUX[ NormFrame ]              SPECTRAL_POSITION
> >
> > The "SPECTRAL_POSITION" Frame would describe frequency, wavelength,
> > velocity, etc, The "FLUX" Frame would describe the flux units, and
> > would encapsulate another Frame (labelled "NormFrame") which describes
> > the coordinate system in which the flux values are normalised (wavelength,
> > frequency, pixel, etc). A method to find the flux, F, at a given position,
> > X, normalised to the system in which the position X is specified, would
> > then work as follows:
> >
> >    - Use [WCS] to find the index, P, of the pixel which includes
> >      position X.
> >    - Use [WCS] to find the width, W1, of pixel P in the frame in which
> >      position X is given.
> >    - Use [WCS] to find the width, W2, of pixel P in the "NormFrame"
> >      frame (there are known, canonical Mappings between any pair of
> >      frames describing spectral positions).
> >    - Use [UNITS] to convert the value of pixel P into the FLUX frame
> >    - Convert this flux value from the FLUX frame (i.e. normalised in the
> >      system specified by NormFrame) to the required frame, by multplying
> >      it by W2/W1.
>
> I *think* I follow this..and agree, with the sole exception/nitpick that
> I dont see why we must limit having framesets defined in terms of
> positional systems. (for example, in your above example things revolve
> around passing pixel coordinates. I would like to think we could do the
> same abound non-positional things like "lambda" as well, consider a
> "reverse" example where I can use the "lamdba" value to find the "pixel"
> on an image that contains an echelle spectra. Other mapping examples may
> have no positions at all (such as flux to magnitude)).

Again, apologies for my overloaded use of the word "position". Frames can
indeed pass things like lambda around, and your reverse example fits well
into the model.


> So to reinterate: I agree WCS forms a critical set of transforms/mappings
> we must include...I just want to insure that other kinds of
> transformations can be done with the same system.

Absolutely agree.

David

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project                        Centre for Astrophysics
(http://www.starlink.ac.uk/)            University of Central Lancashire
Rutherford Appleton Laboratory          PRESTON
DIDCOT                                  United Kingdom
United Kingdom                          PR1 2HE
OX11 0QX