[QUANTITY] Quantity "arguments"
David Berry
dsb at ast.man.ac.uk
Thu Nov 13 10:45:39 PST 2003
Ed,
> >I have no trouble at all with binned values since that is the only
> >thing we *ever* have.
> >
> Not so. There are quantities that refer to the value of a phenomena at
> a specific point in a space. Even flux is sometimes referred to at flux
> at a given frequency with no binning over a frequency range. One can fit
> a spectrum and then extract the flux at specific frequencies. Not all
> measurements are done on a continuous space. Measurement of anything
> done on objects at different specific temperatures or pressure, etc.
> The Quantity object should be general enough to describe any scatterplot
> as well as any histogram as well as any image.
If a measurement refers to a specific zero-width point in some coordinate
space it just means that the pixel width is zero - the coordinate space is
still just a normal continuous coordinate space. And a single pixel is
simply a pixel array containing a single element, pixel coords can still
be defined. It is no different from a "normal" multi-element pixel array -
it just so happens the array contains only a single value. The WCS
FrameSet would contain a pixel Frame, a Mapping, and a Frame for whatever
your coordinate system was:
<WCS> (a FrameSet)
<PixelFrame naxis="1">
<SpecFrame system="freq" unit="GHz" restframe="topocentric" >
<ConstantMap Nin="1" Nout="1" Con1="1.34526">
</WCS>
So here a 1D PixelFrame is connected to a SpecFrame representing
topocentric frequency in GHz using a ConstantMap which has 1 input and 1
output. A ConstantMap is a subclass of Mapping which simply assigns
constant values to each of its outputs. So this FrameSet associates a
frequency of 1.34526 GHz with *all* pixel coordinates. Other classes of
Mapping could be used - for instance one could define a DeltaMap (a
delta function) which assigns a specified constant output value to a
specified input value, and returns a "bad" value (indicating "no value is
available" - like the FITS "BLANK" keyword) at all other input positions.
Just depends what effect you want.
> Well, here is another option
> FluxQ
> Argument
> ProjectedDistanceQ
> ValueList
> 0.1 0.7 1.4 0.3 3.6 6.8
> Units
> parsecs
> ValueList
> 23.2 12.3 5.3 15.7 33.3 5.6
> Units
> ergs/s/cm2/hz
>
> This may convey all of the information that I have or want to convey. I
> see no reason here to mess with mappings or algorithms or frames or
> pixels. Again, these may be binned or may not be binned, perhaps they
> are the fluxes of globules at these specific radii.
The reason for describing this in terms of Mappings and Frames is because
they provide a natural description of what you want to know from the
structure. Client software will typically ask a questions such as "what is
the profile value, y, at a radial distance of x parsecs?" or "what is the
pixel coordinate, p, which corresponds to a profile value of y?". Both of
these questions asks the Quantity to transform (=map) an input value given
in a specified coordinate system, into an output value in some other
output coordinate system. Therefore, I would say that the most natural
description of the Quantity is in terms of the available coordinate
systems (=Frames) and the Mappings between them.
My equivalent to the above would look like:
FluxQ
WCS
<PixelFrame naxis="1">
<Frame naxis="1" unit="parsec">
<LutMap table="0.1,0.7,1.4,0.3,3.6,6.8">
ValueList
23.2 12.3 5.3 15.7 33.3 5.6
Units
ergs/s/cm2/hz
So you see it has very little extra baggage, and allows us to model all
cases uniformly (I would say that the Units component should also be a
FrameSet which describes the known pixel value systems and how to
transform between them, just like WCS).
> On the other hand often we do want to generate axes by algorithm. Then
> one needs an index object that is to mapped. And, when working with the
> special case of continuous curvilinear coordinates, we want to use
> Arguments of the type developed in WCS. WCS is a subclass of Argument
> in which the independent variable needs to begin with a pixelMapQ
> (perhaps tuple to express X,Y) that is mapped to the physical coordinates.
> The frame0 is a subclass of Q that generates that pixelMap. Frame0 is
> mapped by the appropriate WCSMapping. And Frame1 is the input into
> this Mapping. The following fits into your world view as I understand
> it, but perhaps does not nest the way that you prefer. However, it
> allows for a much more general world view.
>
> Quantity
> <values>
> <units>
> WCS:Argument
> Frame0_Q
> WCS:Mapping
> Input
> Frame1
>
> Frame0_Q is a special quantity that provides a shorthand for the following
> if we want tuple. Although, we may decide it is best to use a 1-d index
> number. That depends on the specific algorithm to be used.
>
> PixelMapQ
> Index NAxis1*NAxis2...
> Mapping
> ToTupleAlgorithm
> Input
> NAxis1
> NAxis2
> ...
>
>
> Mapping may also be applied separately on the upper Quantity values.
> For instance to Map to new units:
>
> Quantity
> ValueList
> Units
> Mapping
> ToNewUnits
> Input
> Jansky
> WCS:Argument
> same as before
> This Mapping has nothing to do with the coordinates so why should it
> be in the Argument part?
No reason at all. I agree that we should have some system for allowing
(say) alternative calibrations to be stored in the Quantity. It would
seem natural to me to make the <Units> component hold a FrameSet in which
the base Frame represents the stored pixel value and the other Frames
represent systems into which the stored pixel value can be transformed.
> I can have several WCS:Arguments that would then be separate dimensional
> extensions of the space. And, I can intermix with these ordinary
> Arguments in which the "coordinate" values are explicitly listed.
> For instance images of the same object taken by various spacecraft can
> have Arguments with the names of the spececraft or PI or filterName as
> the independent variable. Indeed, Arguments take Qs, and Qs can have
> complex Arguments (pressure depends on the T and T depends on RA,DE, but
> the ordering of the P is by Temperature).
I'm by no means new to the world of astronomical software, but I'm afraid
you have lost me in a lot of the above. It seems a very involved system to
describe something very simple:
Quantity
<values>
<units>
<wcs>
<PixelFrame naxis="2">
<SkyFrame system="FK5" equinox="J2000" epoch="2003.2">
<CmpMap nin="2" nout="2">
...
...
</CmpMap>
The WCS contains a Mapping (a CmpMap - i.e. a compound Mapping which is
made up from several simpler Mappings) which implements a FITS-WCS style
recipe. This Mapping converts pixel coords to sky coords (FK5,J2000). Why
do we need anything more than this?
If I understand anything of your system, it seems to be saying that axes
are represented by sets of discrete axis values stored in a Quantity.
These may for convenience be generated by an algorithm, based on another
Quantity holding a discrete set of algorithms. But the axis is still
discrete either way. So what do you do if the client is interested in a
position which is not in your set of discrete axis values? For instance, a
client asks for the image value at a particular RA and Dec which turns
out not to correspond to a pixel centre. How do you find the correct pixel
coordinates at which to interpolate the image data? Do you just do linear
interpolation in the tabulated values?
A lot of the complexity of your system seems to be involved with
generating discrete axis or index values (which are then transformed
using mappings). I think it is this aspect of it which seems a bad idea
to me. It adds complexity, its places unnecessary restrictions on the axis
values, and it just seems unnatural because the Quantity itself should not
specify the axis values which the client software is going to be
interested in. How can the Quantity know what axis values the client
software is going to be interested in?
Our model is simpler because it does away with all the apparatus for
representing actual axis values, and instead expects the client to provide
the input axis values. What is the problem with this simpler approach
which your approach is trying to solve?
Of course, I may be mis-understanding your model completely...
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
More information about the dm
mailing list