[TRANSFORM] What is a "frame"? (Was: Re: [QUANTITY] Justification for Matrix Quantities)

[Brian Thomas]

On Tuesday 04 November 2003 11:46 am, David Berry wrote:
> > 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. 
> [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?

> 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.

	Yes, you are right. The user should be allowed an option to get their
	values in either way (e.g. in the example above w/ or w/o the "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.

	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)).
	
	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.

 	Regards,

	=b.t.


-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128