Index: /trunk/doc/modules/CameraImages.tex =================================================================== --- /trunk/doc/modules/CameraImages.tex (revision 5358) +++ /trunk/doc/modules/CameraImages.tex (revision 5359) @@ -724,2 +724,227 @@ 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. + Index: /trunk/doc/modules/ModulesSDRS.tex =================================================================== --- /trunk/doc/modules/ModulesSDRS.tex (revision 5358) +++ /trunk/doc/modules/ModulesSDRS.tex (revision 5359) @@ -1,3 +1,3 @@ -%%% $Id: ModulesSDRS.tex,v 1.59 2005-09-20 22:01:33 jhoblitt Exp $ +%%% $Id: ModulesSDRS.tex,v 1.60 2005-10-18 14:07:17 eugene Exp $ \documentclass[panstarrs,spec]{panstarrs} @@ -1204,4 +1204,52 @@ \item \code{MASK.NAME} (STR): Name of mask image \end{itemize} + +\subsection{Fringes} + +Some images contain a signal caused by thin-film interference in the +device due to strong emission lines. The resulting instrumental +effect consists of a pattern (the fringe pattern) of bright and dark +bands corresponding to the constructive and destructive interference +of the emission lines. In the case that a single emission line causes +the line structure, the resulting pattern can be described by two +independent parameters: First, the amplitude of the emission line +determines the overall amplitude of the pattern. Second, the +three-dimensional surface structure of the device determines the shape +of the pattern. In a typical situation, the device is not only +illuminated by the emission line (or lines), but also by a continuum +spectral source, which contributes to the overall light detected by +the device without following the fringe pattern. The relative +intensities of the continuum background and the fringe pattern depend +on the device structure (thickness) and on the ratio of the continuum +and line emission fluxes. + +A simple approach to the fringe pattern is to subtract a master fringe +frame scaled by the amplitude of the fringe pattern. We thus need a +method of measuring the fringe amplitude which is robust in the +presence of stars and which is fast. We implement a method used at +CFHT in which the fringe pattern is mapped by a series of points pairs +which correspond to peaks and valleys of the fringe pattern. We +define the following function to measure the global fringe amplitude +of an image given a collection of fringe point pairs. +\begin{prototype} +stats *pmFringeStats (psImage *image, psArray *fringePoints, psMetadata *config); +\end{prototype} +This function measures the robust median at each of the minimum and +maximum coordinates and determines the difference and mean of the two +values. From the collection of differences, the robust median is +calculated, and returned as part of the fringe statistics. + +The \code{fringePoints} are defined by the following structure: +\begin{datatype} +typedef struct { + double xMin; + double yMin; + double xMax; + double yMax; + double delta; + double midValue; +} pmFringePoint; +\end{datatype} + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%