[QUANTITY] Quantity "arguments"

[David Berry]

Ed,

> We are ultimately trying to represent the image produced by a telescope
> of the electromagnetic flux as a function of position on the sky.  It is
> binned because of the finite size of our detectors and that is one
> degradation  from a perfect  representation.  But you say elsewhere that
> you do not have trouble with  a quantity holding a binned value.
> Several hundred words are saved.

I have no trouble at all with binned values since that is the only
thing we *ever* have. I think the natural language for describing a
Quantity should recognise this and talk in terms of dependancy on pixel
number and not (RA,Dec). Several more hundred words are saved.


> The next problem is the position on the sky measurements.  We know to a
> certain accuracy the direction in the sky for each pixel.  This is done
> through various measurements of the positions of gears and calibrations
> of the telescope and zeroing on some set of fiducial stars etc.  So
> certainly the position in the sky of each binned number is a measured
> quantity.  That is also not your issue since you allow quantity to hold
> binned numbers, which are after all numbers.

Yes indeed. One could create a Quantity holding the (RA,Dec) values at the
centre of every pixel - if you were interested in the pixel centres. But
of course you could equally be interested in the pixel corners, or any
other point within the pixel. So rather than storing (explicitly *or*
implicitly) the numerical pixel centre coordinates, a Quantity should
store the *algorithm* for creating the coordinates at any given pixel
position. Which is why I say that it is better to conceive WCS as a
collection of algorithms and coordinate systems rather than as a set of
nested Quantities holding numerical axis values.

> The remaining issue is the choice of the coordinate system to use.  The
> image is a function of position on the sky, but one could choose to
> express this in equatorial, galactic, supergalactic, ecliptic systems.
> One could choose various equinox years and one could make up one's own
> coordinate system that is better suited to the issue, like polar
> coordinates centered on the nucleus of the galaxy.  There is often a
> more natural coordinate system because the pixels are rectangular and
> are usually aligned with the RA,DE lines and so there is some added
> benefit in using the coordinate system to which the camera is aligned.
> Here is where, if I understand correctly, you prefer to be somewhat
> non-committed to a particular coordinate system, keep the data expressed
> as a function of the pixel number or tuple (35,234), and express
> the WCS equatorial-frame of the pixel map or some other coordinate frame
> and/or express transformations to other coordinate frames.  Well,
> surprise, I do NOT disagree.  If you look at my example, the positionQ
> Argument to  fluxQ IS in terms of pixel tuples and then I added a
> WCSMapping which allowed one to transform to either a RA,DE frame or a
> Galactic frame. In fact my example has the pixels even more "primary"
> than you would have it because I give no expression to any specific sky
> coordinate system until a WCSMapping is performed.

Not sure I understand the last sentence, but yes, there are many features
in common between out models.

> So where do we really disagree?  Is it because you see that our model
> ALLOWS a flux quantity to have an Argument of a particular frame and to
> bypass the pixel frame?  Indeed,  we are asking for permission to
> respond to a query for say flux as a function of
> lambda=(.6,.7,.8,.9,1.0) microns to be expressed as a flux valuelist
> with an Argument being the lambda valuelist directly.  Are we to
> respond, sorry but your request does not fit to our model, please
> rephrase in terms of a pixel map?

The request does fit exactly into our model. The typical questions which
would be asked of the result from such a query are "Give me the 10th flux
value" and "give me the 10th wavelength value". Both of these are simple
straightfoward examples of Mappings, the input being the "pixel number"
10 (in the general sense of a "pixel" being any data element), and the
output being the requested flux or wavelength value. Another valid request
would be "give me a Quantity containing the wavelength at each pixel
centre" - in this case the invoked method would construct a new Quantity
and fill its ValueList by using the WCS component of the original flux
Quantity to convert each integer "pixel" index into the corresponding
wavelength value.

There are obviously many points of contact between your model and ours. I
think the real point where we disagree is whether it is more natural to
conceive a set of axes as a collection of numerical values (and therefore
describe them using nested Quantities), or as a set of coordinate systems
with inter-relating algorithms (and therefore describe them as a
FrameSet). Choosing the most natural language to describe a problem is
usually important because it helps you to produce a simpler and clearer
interface.

> Or for spatial fluxes, we want to respond that after adding together all
> of the data from all ground and space based data we have fluxes, as
> requested, as a function directly of galactic coordinates.  I added the
> space based data, because in general the pixels are not aligned with any
> particular coordinates.  In fact the data may include those from a
> spinning, scanning instrument that puts out strips.  Therefore the shape
> of the pixels may be too complex to describe and the requestor may not
> really caree.

I'm not sure I understand your point here. Are you suggesting that the
model we propose would not be able to describe this situation naturally?
At the end of the day, all your data will be organised in some data
structure which will be accessed using some indexing system ("pixel
coords"), and you will be interested in some other coordinate systems,
including galactic, etc. The function which transforms one into the other
is the Mapping. The WCS component contains descriptions of all the
coordinate systems you are interested in, together with Mappings to get
you between them.


> In most cases, where the request is for a subset or the whole of a
> particular exposure, then I agree that the pixel coordinates should be
> in the quantity because it is faster to express this plus a Mapping than
> to list out each coordinate of each pixel.

We may not be understanding each other. I do not think the pixel coords
should be "in" the Quantity - we should avoid storing numerical axis
values, in any coord system (including pixel), unless it is absolutely
necessary (e.g. because there is no underlying "projection" algorithm).
In my view, the pixel coords are supplied by the client software. That is,
the client software says what pixel coord it is interested in, and the
Quantity (actually the WCS component) returns the corresponding "world"
coords.


> But, one should not go too
> far in this direction because we should not dictate that a particular
> set of axis values cannot be used because it may be transformed to some
> other.  For instance, if one has calculated, from an image, a flux
> versus projected distance in parsecs from a planetary nebula, we can't
> insist that this be primarily expressed as a pixel array just because
> someone else may want it in centimeters.  This is clearly a case where
> one has a FluxQ with Argument ProjectedDistanceQ in parsec.  If you want
> centimeters, then that is an external process.  We do however need to
> carefully express the radial bin sizes used.

Afraid I disagree again. The example you give fits exactly into our
model. If you have a radial profile, how else are you going to store it
other than as some form of pixel array? I do not see any other option. The
ValueList in the Quantity will contain a list of flux values (="pixels"),
with indices (="pixel coord") running from 1 (or 0 - for Brian!) to say,
100. The WCS component will contain a 1-D Frame representing distance in
parsecs, and a Mapping (probably just a simple linear Mapping) which
converts a pixel coords into a distance in parsecs. I do agree however,
that converting parsecs to centimetres would be an external process,
unless of course the centimetres measure distance on the telescope focal
plane instead of distance from the centre of the nebula. In this case you
could simply have an extra Frame in the WCS FrameSet to describe
centimetres in the focal plane.




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