[QUANTITY] Justification for Matrix Quantities

[David Berry]

Brian,

> > Using the sort of [WCS] idea I've mentioned in the past, this sort of
> > Quantity would have a WCS component which could be represented as a tree:
> >
> >                        PIXEL
> >                        / | \
> >        ----------------  |  ------------------
> >        |                 |                   |
> >       SKY           FOCAL_PLANE        PARENT_PIXEL
> >
> > Each word represents a "Frame" object (i.e. a description of a coordinate
> > system, e.g. using Arnold Rots STC schema), and each dashed line
> > represents a "Mapping" object (i.e. a recipe which describes how to
> > transform positions between the two Frames connected by the line).
>
> Yes, I believe we agree, with minor differences in  the semantic
> difference of "Frame" vs. "set of quantities" is our difference, and
> that I would prefer that some "primary" frame (say pixels in {x,y})
> exists within the quantity being interrogated. I desire this primary
> frame because it has impact on the dimensionality of the units. Consider
> that a F(lambda) array has values which are in units of erg cm^-2 s^-1
> wavelength^-1. If I choose to store F(i) (where "i" is a dimensionless
> pixel index) then the units are different, e.g. erg cm^-2 s^-1 pixel^-1.
> Thus, "set" holds information of "frame" but further may include
> information about unit dimensionality, and thus, a "primary" set is
> needed.

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. If you have an array of flux values and a
method to return the flux at a given position, are you saying that you
want the returned value converted to different units depending on how you
specify the position (i.e. erg.cm^-2.s^-1.m^-1 if you specify the position
as a wavelength, erg.cm^-2.s^-1.Hz^-1 if you specify the position as a
frequency, etc)? Whilst the change in returned units may be nice, it is
not a logical necessity of specifying the position in different a system -
you *could* legitimately return the value in erg.cm^-2.s^-1.m^-1 even if
you specified the position in Hz.

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.

> > One more question about your scheme... when you have quantities which are
> > functions of other quantities, do the argument quantities contain actual
> > numerical values? Back to the CCD example, we have a quantity representing
> > the flux values - this quantity presumably contains the actual flux values.
> > In your model this quantity is a function of another quantity representing
> > sky position. Does this sub-quantity also contain arrays of actual
> > numerical RA and DEC values?
>
> Yes, the sub-quantity it may be actual arrays of numerical values OR these
> values may be generated from an underlying algorithm.

So there would be no need to store values for the RA and DEC of every
pixel in an image (just checking)??

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