Changeset 5359 for trunk/doc/modules/CameraImages.tex

Timestamp:

Oct 18, 2005, 4:07:17 AM (21 years ago)

Author:

eugene

Message:

added astrometry matching tools, fringes

File:

• trunk/doc/modules/CameraImages.tex (modified) (1 diff)

trunk/doc/modules/CameraImages.tex

@@ -724 +724 @@
 output; otherwise it shall return \code{false}.
 
+\subsection{Astrometry Fitting Support Routines}
+
+Astrometry is performed on an astronomical image after a collection of
+sources in the image have been detected and thier instrumental
+positions have been measured.  In this collection of tools, the
+coordinates should be measured in the frame of the \code{pmReadout}
+portion of the Image Hierarchy.  This potentially allows us to measure
+an astrometric transformation resulting from the transformation to any
+of the other coordinate system.  For example, it might be necessary to
+determine the coordinates of the \code{psReadout} pixels relative to
+the \code{psCell} (rather accept the relationship defined by the
+metadata).  
+
+For the moment, we define two layers of astrometric analysis which
+will be performed on typical mosaic images in the Pan-STARRS IPP:
+per-chip astrometry and per-mosaic astrometry.  In the first case, a
+collection of detections across a single chip are used to determine a
+basic, linear transformation to celestial coordinates.  This
+astrometric analysis can be used to determine an initial, approximate
+astrometry for each chip in a mosaic camera, with accurcy limited by
+the effects of optical distortion (a few pixels error, typically).  In
+the second case, a collection of detectors on a collection of chips
+from a mosaic camera are used to measure the position of the telescope
+boresite, the camera rotation, the impact of distortion from the
+telescope optics, and the chip-to-focal plane transformation resulting
+from chip placement errors or possible detector tilts or warps.  
+
+The process of performing astrometry involves the following steps:
+\begin{itemize}
+\item Make an initial guess at the celestial coordinates of the raw
+  detections (eg, from metadata or image header information).
+\item Determine, and load, stars from an astrometric catalog which may
+  potentially correspond to the raw detections.
+\item Project both raw and reference stars to a common coordinate
+  frame (here we use the Focal Plane as an appropriate coordinate
+  system). 
+\item Identify matches between the raw and reference stars.
+\item Determine the transformations necessary to relate the
+  coordinates of the two sets of stars.
+\item Convert the measured transformations into appropriate terms in
+  the astrometric elements of the Image Hierarchy.
+\end{itemize}
+In this section, we specify several functions which together make
+possible the above analysis steps.  
+
+We define the following structure to carry the necessary information
+about each detection.  
+\begin{datatype}
+typedef struct {
+    double X, Y;
+    double P, Q;
+    double L, M;
+    double R, D;
+    double Mag;
+} pmAstromObj;
+\end{datatype}
+This structure specifies the coordinate of the detection in each of
+the four necessary coordinate frames: \code{X,Y} define the position
+in the \code{psReadout} frame, \code{P,Q} define the position in the
+\code{psChip} frame, \code{L,M} define the position in the
+\code{psFPA} frame, \code{R,D} define the position on the Celestial
+Sphere.  \tbd{re-write using psPlane and psSphere?}.  In addition, a
+measurement of the brightness is given by the element \code{Mag}.
+Such a data structure should be used for both the raw and the
+reference stars.  In astrometric processing, the raw detections will
+be projected using the best available information to each of these
+coordinate frames from the \code{X,Y} coordinates, while the reference
+detections will be projected to the other frames from the \code{R,D}
+coordinates.
+
+The raw detections and the reference stars are both projected to a
+common coordinate frame for analysis.  In these modules, we
+principally use the Focal Plane for this reference frame.  After
+projection to the common frame, it is necessary to determine the match
+between corresponding objects in the two lists.  In order to match the
+raw detections to the reference stars, different methods are used
+depending on the circumstance.  
+
+If the two sets of coordinates are expected to agree very well (ie,
+the current best-guess astrometric solution is quite close to the
+'true' astrometric solution), then it is possible to use the simplest
+matching process: cross-correlation within a fixed radius.  The
+following function accepts two sets of \code{pmAstromObj} sources and
+determines the matched objects between the two lists.  The input
+sources must have been projected to the Focal Plane coordinates
+(\code{pmAstromObj.P,Q}), and the supplied \code{config} entry must
+contain the desired match radius (keyword:
+\code{ASTROM_MATCH_RADIUS}).  The output consists an array of
+\code{pmAstromMatch} values, defined below.
+
+\begin{prototype}
+psArray *pmAstromRadiusMatch (psArray *st1, psArray *st2, pmAstromOpt *opt);
+\end{prototype}
+
+\begin{datatype}
+typedef struct {
+    int i1;
+    int i2;
+} pmAstromMatch;
+\end{datatype}
+The \code{pmAstromMatch} structure defines the cross-correlation
+between two arrays.  An single such data item specifies that item
+number \code{pmAstromMatch.i1} in the first list corresponds to
+\code{pmAstromMatch.i2} in the second list.  
+
+If the two sets of coordinates are not known to agree well, a somewhat
+different approach is needed.  Several algorithms have been defined in
+the past to correlate two lists with unknown offsets, and potentially
+unknown relative rotations and scaling.  One well-known method is the
+triangle-match algorithm which searches for similar triangles observed
+in the two lists.  This algorithm has the advantage of not requiring
+the rotation or the scale to be well-known in advance.  The
+disadvantage of the triangle match algorithm is that it is necessarily
+an $O(N^3)$ process since it is necessary to construct a substantial
+fraction of all possible triangles for both input lists.  \tbd{we do
+  not define a triangle match algorithm at this time}.
+
+If the two sets of coordinates are not known to agree well, but the
+relative scale and approximate relative rotation is known, then a much
+faster match can be found using pair-pair displacements.  In such a
+case, the two lists can be considered as having the same coordinate
+system, with an unknown relative displacement.  In this algorithm, all
+possible pair-wise differences between the source positions in the two
+lists are constructed and accumulated in a grid of possible offset
+values.  The resulting grid is searched for a cluster representing the
+offset between the two input lists.  This algorithm can only tolerate
+a small error in the relative scale or the relative rotation of the
+two coordinate lists.  However, this process is naturally $O(N^2)$,
+and is thus advantageous over triangle matching in some circumstances.
+This process can be extended to allow a larger uncertainty in the
+relative rotation by allowing the procedure to scan over a range of
+rotations.  We define the following function to apply this matching algorithm: 
+\begin{prototype}
+pmAstromGridMatchStat pmAstromGridMatch (psArray *st1, psArray *st2, psMetadata *options);
+\end{prototype}
+The input sources must have been projected to the Focal Plane
+coordinates (\code{pmAstromObj.P,Q}), and the supplied \code{config}
+entry must contain the following user-defined parameters:
+\begin{itemize}
+\item GRID_OFFSET : maximum allowed displacement in search
+\item GRID_SCALE  : grid bin size in focal-plane coordinate units
+\item MIN_ANGLE : minimum tested relative rotation 
+\item MAX_ANGLE : maximum tested relative rotation 
+\item DEL_ANGLE : relative rotation step size
+\end{itemize}
+The output from this process is the statistics of the best-fit
+(rotation and offset grid cell).  This information is returned in the
+\code{pmAstromGridMatchStats} structure:
+\begin{datatype}
+typedef struct {
+    double angle;
+    double dP;
+    double dQ;
+    double minMetric;
+    double minVar;
+    int    nMatch;
+} pmAstromGridMatchStats;
+\end{datatype}
+The elements \code{angle}, \code{dP}, \code{dQ} define the best
+rotation and offset; the element \code{nMatch} indicates the number of
+matched sources which fell within the match bin; the element
+\code{minVar} defines the variance of the sources within the match
+bin; the element \code{minMetric} specifies the value of the selection
+metric for the matched bin.  Note that the metric of choice may not
+necessarily be either the simple number of sources or the varience.
+We find that a combination based on both which enhances the importance
+of having a well-populated bin with a minimal variance gives good
+results: $\mbox{metric} = \mbox{var} \times N^{-4}$.  
+
+We define two additional functions which are used in two build
+\code{pmAstromGridMatch}, but which may be useful on their own:
+
+\begin{prototype}
+pmAstromGridMatchStats pmAstromGridMatchAngle (psArray *st1, psArray *st2, psMetadata *config);
+\end{prototype}
+This function is identical to \code{pmAstromGridMatch}, but is valid
+for only a single relative rotation.  The input \code{config}
+information need not contain any of the \code{ANGLE} entries. 
+
+\begin{prototype}
+psArray *pmAstromRotateObj (psArray *old, double angle, double pCenter, double qCenter);
+\end{prototype}
+This function accepts an array of \code{pmAstromObj} objects and
+rotates them by the given \code{angle} about the given center
+coordinate \code{pCenter,qCenter} in the Focal Plane Array
+coordinates.  
+
+The result of a \code{pmAstromGridMatch} may be used to modify the
+astrometry transformation information for a \code{pmFPA} image
+hierarchy structure.  The result of \code{pmAstromGridMatch} defines
+the adjustments which should be made to the reference coordinate of
+the projection (\code{pmFPA.projection.R,D}) and the effective
+rotation of the Focal Plane.  The rotation implies modification of the
+linear terms of the \code{pmFPA.toTangentPlane} transformation.  These
+two adjustments are made using the function:
+\begin{prototype}
+pmAstromApplyGridMatch (pmFPA *fpa, pmAstromGridMatchStats stats);
+\end{prototype}
+This function modifies the supplied \code{pmFPA} entry as described
+above.
+
+The result of a \code{pmAstromRadiusMatch} operation is a list of
+matched entries between the two input lists.  This list may be used to
+determine a linear fit between the two sets of matched sources.  The
+following function performs this operation:
+\begin{prototype}
+bool pmAstromMatchedListFit (pmFPA *fpa, psArray *st1, psArray *st2, psArray *match, psMetadata *config);
+\end{prototype}
+This function accepts the raw and reference source lists and the list
+of matched entries.  It uses the matched list to determine a
+polynomial transformation between the two coordinate systems.  The
+fitting uses clipping to exclude outliers, likely representing poor
+matches.  The \code{config} element must contain the information
+\code{ASTROM_NSIGMA} (specifying the number of sigma used in the
+clipping) and \code{ASTROM_NCLIP} (specifying the number of clipping
+iterations must be performed).  The \code{config} element must also
+specify the order of the polynomial fit (keyword:
+\code{ASTROM_ORDER}).  The result of this fit is a set of
+modifications of the components of the \code{pmFPA.toTangentPlane}
+transformation, and the modifications of the reference coordinate of
+the projection (\code{pmFPA.projection.R,D}) and the projection scale
+(\code{pmFPA.projection.Xs,Ys}).  The modifications to
+\code{pmFPA.toTangentPlane} incorporate the rotation component of the
+linear terms and the higher-order terms of the polynomial fits.
+