Changeset 2502
- Timestamp:
- Nov 26, 2004, 3:48:23 PM (22 years ago)
- Location:
- trunk/doc/pslib
- Files:
-
- 3 edited
-
ChangeLogSDRS.tex (modified) (3 diffs)
-
psLibSDRS.tex (modified) (16 diffs)
-
psLibSDRS_Astrom.tex (modified) (22 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/pslib/ChangeLogSDRS.tex
r2372 r2502 1 %%% $Id: ChangeLogSDRS.tex,v 1.4 6 2004-11-16 02:20:27 price Exp $1 %%% $Id: ChangeLogSDRS.tex,v 1.47 2004-11-27 01:48:23 eugene Exp $ 2 2 3 3 \subsection{Changes from version 00 to version 01} … … 344 344 \end{itemize} 345 345 346 \subsection{Changes from Revision 08 (12 October 2004) to Revision 09 ( ???)}346 \subsection{Changes from Revision 08 (12 October 2004) to Revision 09 (15 November 2004)} 347 347 348 348 \begin{itemize} … … 380 380 \end{itemize} 381 381 382 \subsection{Changes from Revision 09 (15 November 2004) to Revision 10 (???)} 383 384 \begin{itemize} 385 \item changed psFitsReadHeaderSet to return a psMetadata rather than just a psHash 386 \item added METADATA ... END construction in psMetadataParseConfig 387 \item added psArrayAdd function to Simple Arrays 388 \item added utility functions \code{psMetadataLookupPtr}, \code{psMetadataLookupS32}, \code{psMetadataLookupF64} 389 \item added \code{psArrayFromHash} 390 \item changed name of \code{psListToArray} to \code{psArrayFromList} and vice versa (keeping with the output data matching the type). 391 \item re-organization of the astronomical images section: placed constructors with structures. 392 \end{itemize} 393 -
trunk/doc/pslib/psLibSDRS.tex
r2383 r2502 1 %%% $Id: psLibSDRS.tex,v 1.15 3 2004-11-18 23:54:32 price Exp $1 %%% $Id: psLibSDRS.tex,v 1.154 2004-11-27 01:48:23 eugene Exp $ 2 2 \documentclass[panstarrs,spec]{panstarrs} 3 3 … … 19 19 \maketitle 20 20 \sloppy 21 22 % make a margin comment: 23 % \marginpar{note!} 21 24 22 25 % -- Revision History -- … … 35 38 06 & 2004 Aug 19 & revision for cycle 3 \\ \hline 36 39 07 & 2004 Sep 07 & final for cycle 3 \\ \hline 37 08 & 2004 Oct 12 & draft for start of cycle 4 \\ 40 08 & 2004 Oct 12 & draft for start of cycle 4 \\ \hline 41 09 & 2004 Nov 15 & final for cycle 4 \\ 38 42 \RevisionsEnd 39 43 … … 307 311 follows: 308 312 % 313 \filbreak 309 314 \begin{verbatim} 310 315 typedef struct { … … 700 705 reference counter and returns.} An example destructor is shown below: 701 706 707 \filbreak 702 708 \begin{verbatim} 703 709 void psMyTypeFree(psMyType *myType) … … 1466 1472 1467 1473 \begin{verbatim} 1474 psArray *psArrayAdd(psArray *array, int delta, void *value); 1475 \end{verbatim} 1476 1477 This function adds a value to the end of an array. If the current 1478 length of the array (\code{psArray.n}) is at the limit of the 1479 allocated space, additional space is allocated. The value of 1480 \code{delta} defines how many elements to add on each pass (if this 1481 value is less than 1, 10 shall be used). 1482 1483 \begin{verbatim} 1468 1484 psArray *psArraySort(psArray *array, int (*compare)(const void **a, const void **b) ); 1469 1485 \end{verbatim} … … 1646 1662 1647 1663 \begin{verbatim} 1648 psArray *ps ListToArray(psList *list);1649 psList *ps ArrayToList(psArray *array);1664 psArray *psArrayFromList(psList *list); 1665 psList *psListFromArray(psArray *array); 1650 1666 \end{verbatim} 1651 1667 These two functions are available to convert between the … … 1746 1762 returns the complete list of defined keys associated with the 1747 1763 \code{psHash} table as a linked list. 1764 1765 \begin{verbatim} 1766 psArray *psArrayFromHash(psHash *hash); 1767 \end{verbatim} 1768 This function is available place the data in a \code{psHash} into a 1769 \code{psArray} container. This function does not free the elements or 1770 destroy the input collection. Rather, it increments the reference 1771 counter for each of the elements. The resulting array does not have 1772 any information about the has key values, and the order is not 1773 significant. 1748 1774 1749 1775 \subsection{Lookup Tables} … … 2120 2146 psHistogram *psVectorHistogram(psHistogram *out, 2121 2147 const psVector *values, 2122 2148 const psVector *errors, 2123 2149 const psVector *mask, 2124 2150 unsigned int maskVal); … … 2367 2393 bool psMinimizeLMChi2(psMinimization *min, psImage *covar, psVector *params, 2368 2394 const psVector *paramMask, const psArray *x, const psVector *y, 2369 2395 const psVector *yErr, psMinimizeLMChi2Func func); 2370 2396 \end{verbatim} 2371 2397 … … 3738 3764 3739 3765 We define an item of metadata with the following structure: 3766 \filbreak 3740 3767 \begin{verbatim} 3741 3768 typedef struct { … … 3767 3794 \code{psMetadataType}: 3768 3795 % 3796 \filbreak 3769 3797 \begin{verbatim} 3770 3798 typedef enum { ///< type of item.data is: … … 3889 3917 \end{verbatim} 3890 3918 3919 Several utility functions are provided for simple cases. These 3920 functions perform the effort of casting the data to the appropriate 3921 type. The numerical functions shall return 0.0 if their key is not 3922 found. 3923 \begin{verbatim} 3924 void *psMetadataLookupPtr(const psMetadata *md, const char *key); 3925 psS32 psMetadataLookupS32(const psMetadata *md, const char *key); 3926 psF64 psMetadataLookupF64(const psMetadata *md, const char *key); 3927 \end{verbatim} 3928 3891 3929 Items may be retrieved from the metadata by their entry position. The 3892 3930 value of which specifies the desired entry in the fashion of … … 4015 4053 4016 4054 Here are some examples of lines of a valid configuration file: 4055 \filbreak 4017 4056 \begin{verbatim} 4018 4057 Double F64 1.23456789 # This is a comment … … 4064 4103 Figure~\ref{fig:metadata}. 4065 4104 4105 We further extend \code{psMetadataParseConfig} to allow the definition 4106 of a \code{psMetadata} entry using a sequence of successive lines to 4107 define the values of the \code{psMetadataItem} entries. The initial 4108 line defines the new \code{psMetadata} entry and its name. The 4109 following lines have the same format as the other metadata config file 4110 entries. The sequence is terminated with a line with a single word 4111 \code{END}. For example, a metadata entry may be defined as: 4112 \begin{verbatim} 4113 CELL METADATA 4114 EXTNAME STR CCD00 4115 BIASSEC STR BSEC-00 4116 CHIP STR CHIP.00 4117 NCELL S32 24 4118 END 4119 \end{verbatim} 4120 4066 4121 A BNF-like grammar of the configuration file is contained in 4067 4122 \S\ref{sec:configgrammar}. … … 4151 4206 4152 4207 \begin{verbatim} 4153 ps Hash*psFitsReadHeaderSet (psFits *fits);4208 psMetadata *psFitsReadHeaderSet (psFits *fits); 4154 4209 \end{verbatim} 4155 4210 Load a complete set of headers from the \code{psFits} file pointer. -
trunk/doc/pslib/psLibSDRS_Astrom.tex
r1674 r2502 9 9 additional metadata to describe the data in detail. Second, astronomy 10 10 applications frequent involve multiple, related images. For 11 Pan STARRS, and for general astronomical applications, we require a11 Pan-STARRS, and for general astronomical applications, we require a 12 12 richer collection of data structures which describe a very general 13 13 image concept. We have defined several layers in the hierarchy which 14 14 are necessary to describe the image data which will be produced by the 15 Pan STARRS Gigapixel cameras as well as other standard astronomical15 Pan-STARRS Gigapixel cameras as well as other standard astronomical 16 16 images. 17 17 … … 19 19 imaging. If we consider various optical and IR array cameras, a 20 20 single readout of the detector produces a collection of pixels 21 measurements. We define our lowest-level astronomical image 22 structure, \code{psReadout}, to contain the pixels produced by a 23 single readout of the detector, along with metadata needed to define 24 that readout: the origin and binning of the image relative to the 25 original detector pixels explicitly in the structure, and pointers to 26 the general metadata and derived objects, if any. 27 28 A single detector may produce more than one read which is associated. 29 For example, infrared detectors frequently produce an image 30 immediately after the detector is reset followed by an image after the 31 basic exposure is complete. Both readouts correspond to the same 32 pixels, though the binning or rastering may be different between the 33 two readouts. Another example is the video sequence produced by the 34 PanSTARRS Gigapix camera guide cells, each of which represents a 21 measurements which is well represented as a single 2D image. We 22 define our lowest-level astronomical image structure, 23 \code{psReadout}, to contain the pixels produced by a single readout 24 of the detector, along with metadata needed to define that readout: 25 the origin and binning of the image relative to the original detector 26 pixels explicitly in the structure, and pointers to the general 27 metadata and derived objects, if any. 28 29 A single detector may be read multiple times in sequence. For 30 example, infrared detectors frequently produce an image immediately 31 after the detector is reset followed by an image after the basic 32 exposure is complete. Both readouts correspond to the same pixels, 33 though the binning or rastering may be different between the two 34 readouts. Another example is the video sequence produced by the 35 Pan-STARRS Gigapix camera guide cells, each of which represents a 35 36 series of many images from a subraster of pixels in the detector 36 37 readout portion. The second level of our image container hierarchy, … … 38 39 detector. 39 40 40 In the Pan STARRS Gigapix camera, the basic readout region is a41 In the Pan-STARRS Gigapix camera, the basic readout region is a 41 42 fraction of the full imaging area of a single CCD chip. The chip is 42 43 divided into 64 cells, any fraction of which may have been readout … … 59 60 the focal plane consists of these eight chips. 60 61 61 As another example, consider an observation by PS 1. The focal plane62 As another example, consider an observation by PS-1. The focal plane 62 63 would consist of 60 chips, each of which consist of 64 cells (or less; 63 64 a few cells may be dead). Some cells (those containing guide stars … … 76 77 has one \code{psCell}, which in turn has one \code{psReadout}. 77 78 78 These container levels also include in their definition the information 79 needed to transform the coordinates in one of the levels to the 80 coordinate system relevant at the higher levels. 81 82 \subsubsection{A Readout} 79 The data structures defined below provide two additional features 80 beyond the hierarchy of relationships. First, each level of the 81 hierarchy includes a generic \code{psMetadata} pointer to provide 82 whatever metadata would be appropriate for that level. The functions 83 within PSLib do not specify the contents of those metadata containers. 84 One example of their usage is provided in the documentation for the 85 Pan-STARRS IPP collection of data processing modules. 86 87 While the \code{psMetadata} pointers provide a mechanism to carry 88 generic information about the image, the hierarchy of data structures 89 also provides an explicit set of information defining the geometrical 90 relationships between the levels of the hierarchy. Two types of 91 information are provided. In the first case, basic offsets (and in 92 the case of the readouts, binning and flips) are defined to specify 93 the location of a given \code{psCell} with respect to its containing 94 \code{psChip} in the assumption that the pixels in the entire focal 95 plane array are laid out on a uniform grid. This is a crude 96 approximation, and cannot be assumed for careful astrometric analysis, 97 but it can be used as a starting point or to place the the pixels in a 98 test image. For higher precision, detailed astrometric 99 transformations between one frame and the next are also provided. 100 101 \tbd{in the future, it may be worthwhile to migrate all of these 102 additional pieces to the psMetadata since there is no pressing need to 103 have them visible in the data structures} 104 105 \subsubsection{Image Data Container Hierarchy} 106 107 \subsubsubsection{A Readout} 83 108 84 109 A readout is the result of a single read of a cell (or a portion … … 90 115 \begin{verbatim} 91 116 typedef struct { 117 const int col0; ///< Offset from the left of cell. 118 const int row0; ///< Offset from the bottom of cell. 119 const int colParity; ///< Readout Direction X 120 const int rowParity; ///< Readout Direction Y 92 121 const unsigned int colBins; ///< Amount of binning in x-dimension 93 122 const unsigned int rowBins; ///< Amount of binning in y-dimension 94 const int col0; ///< Offset from the left of chip.95 const int row0; ///< Offset from the bottom of chip.96 123 psImage* image; ///< imaging area of Readout 97 psList* objects; ///< objects derived from Readout98 124 psMetadata* metadata; ///< readout-level metadata 99 125 } psReadout; 100 126 \end{verbatim} 101 127 102 \subsubsection{A Cell} 128 The constructor for \code{psReadout} shall be: 129 \begin{verbatim} 130 psReadout *psReadoutAlloc(); 131 \end{verbatim} 132 All pointers in the structure shall be initialized to \code{NULL}. 133 134 \subsubsubsection{A Cell} 103 135 104 136 A cell consists of one or more readouts (usually only one except in the … … 119 151 \begin{verbatim} 120 152 typedef struct { 153 const int col0; ///< Offset from the left of chip. 154 const int row0; ///< Offset from the bottom of chip. 121 155 psArray* readouts; ///< readouts from the cell 122 156 psMetadata* metadata; ///< cell-level metadata … … 124 158 psPlaneTransform* toFPA; ///< transformations from cell to FPA coordinates 125 159 psPlaneTransform* toSky; ///< transformations from cell to sky coordinates 126 struct psChip* parent; ///< chip in which contains this cell160 psChip *parent; 127 161 } psCell; 128 162 \end{verbatim} 129 163 130 \subsubsection{A Chip} 164 The constructor for \code{psCell} shall be: 165 \begin{verbatim} 166 psCell *psCellAlloc(int nReadouts, struct psChip *parentChip); 167 \end{verbatim} 168 The constructor shall make an empty \code{psCell}, with the 169 \code{nReadouts} allocated pointers to \code{psReadout}s being set to 170 \code{NULL}. If \code{nreadouts} is zero or less, then 1 readout 171 shall be allocated. In either case, the value of 172 \code{psCell.readouts.n} should be initially set to 0. If the 173 \code{parentChip} is not NULL, this link is made, otherwise it is set 174 to \code{NULL}. All other pointers in the structure shall be 175 initialized to \code{NULL}. 176 177 \subsubsubsection{A Chip} 131 178 132 179 A chip consists of one or more cells (according to the number of … … 141 188 \begin{verbatim} 142 189 typedef struct { 190 const int col0; ///< Offset from the left of FPA. 191 const int row0; ///< Offset from the bottom of FPA. 143 192 psArray* cells; ///< cells in the chip 144 193 psMetadata* metadata; ///< chip-level metadata 145 194 psPlaneTransform* toFPA; ///< transformation from chip to FPA coordinates 146 195 psPlaneTransform* fromFPA; ///< transformation from FPA to chip coordinates 147 struct psFPA* parent; ///< FPA which contains this chip196 psFPA *parent; 148 197 } psChip; 149 198 \end{verbatim} 150 199 151 \subsubsection{A Focal Plane} 200 The constructor for \code{psChip} shall be: 201 \begin{verbatim} 202 psChip *psChipAlloc(int nCells, psFPA *parentFPA); 203 \end{verbatim} 204 The constructor shall make an empty \code{psChip}, with the 205 \code{nCells} allocated pointers to \code{psCell}s being set to 206 \code{NULL}. If \code{nCells} is zero or less, then 1 cell shall be 207 allocated. In either case, the value of \code{psChip.cells.n} should 208 be initially set to 0. If the \code{parentFPA} is not NULL, this 209 link is made, otherwise it is set to \code{NULL}. All other pointers 210 in the structure shall be initialized to \code{NULL}. 211 212 \subsubsubsection{A Focal Plane} 152 213 153 214 A focal plane consists of one or more chips (according to the number … … 176 237 psFixedPattern* pattern; ///< fixed pattern residual offsets 177 238 const struct psExposure* exposure; ///< information about this exposure 178 const psGrommit* grommit; 239 const psGrommit* grommit; ///< grommit allows conversion from tangent plane to sky 179 240 psPhotSystem* colorPlus; ///< Color reference 180 241 psPhotSystem* colorMinus; ///< Color reference … … 183 244 float chi2; ///< chi^2 of astrometric solution 184 245 } psFPA; 246 \end{verbatim} 247 248 The constructor for \code{psFPA} shall be: 249 \begin{verbatim} 250 psFPA *psFPAAlloc(int nChips, const psExposure *exp); 251 \end{verbatim} 252 The constructor shall make an empty \code{psFPA}, with the 253 \code{nChips} allocated pointers to \code{psChip}s being set to 254 \code{NULL}. If \code{nChips} is zero or less, then 1 chip shall be 255 allocated. In either case, the value of \code{psFPA.chips.n} should 256 be initially set to 0. If the value of \code{exp} is not 257 \code{NULL}, this value shall be assigned an used to set the value of 258 \code{grommit}. Otherwise both shall be set to \code{NULL}. All 259 other pointers in the structure shall be initialized to \code{NULL}. 260 261 Two utility functions are defined to manage the collection of 262 backward-pointing links: 263 \begin{verbatim} 264 bool psFPASetLinks (psFPA *fpa); 265 bool psFPATestLinks (psFPA *fpa); 266 \end{verbatim} 267 The first of these functions constructs the \code{parent} pointers for 268 all entries in a \code{psFPA} structure. The second structure checks 269 the validity of the links in an \code{psFPA} structure and returns 270 \code{TRUE} if they are all correctly assigned, otherwise \code{FALSE}. 271 272 \subsubsection{Coordinate Transformations} 273 274 \begin{figure} 275 \psfig{file=CameraLayout,width=5.5in} 276 \caption{Camera Pixel Layout\label{CameraLayout}} 277 \end{figure} 278 279 These container levels also include in their definition the 280 information needed to transform the coordinates in one of the levels 281 to the coordinate system relevant at the higher levels. 282 283 The data structures define the basic coordinate relationships between 284 all of these data elements. A set of offsets for each level in the 285 data hierarchy specifies the location of the particular set of pixels 286 in the next level of the hierarchy. This is illustrated in 287 Figure~\ref{CameraLayout}. These offsets may be used to define the 288 complete camera layout in the approximating assumption that all pixels 289 in the camera are laid out on a single linear pixel grid. This 290 approximate is sufficient for many basic operations. For more detail, 291 the precise astrometric relationship between each level of the 292 hierarchy may also be made available in the metadata of the data 293 structures. 294 295 In practice, a single readout from a detector may represent only a 296 subset of the complete set of pixels addressed by the {\it cell}. The 297 readout may also have binning applied in both of the two dimensions. 298 There may also be overscan and pre-scan regions in the set of pixels. 299 Finally, the readout direction is not always the same for all detector 300 amplifiers. As shown in Figure~\ref{CameraLayout}, these different 301 concepts are represented in the data hierarchy. The coordinate of the 302 origin of the data grid for one level of the hierarchy in the grid of 303 the containing hierarchy is defined for each data level. For example, 304 the origin of the coordinates for a single chip are located in the 305 camera grid at \code{psChip.cell0,row0}. The \code{psReadout} data 306 level has additional information to specify the details of the readout 307 process. The elements \code{psReadout.colParity,rowParity} specify 308 the parity of the specific readout (readout direction), while the 309 elements \code{psReadout.colBins,rowBins} specify the binning factor 310 in the two dimensions. Note that the value of 311 \code{psReadout.col0,row0} must be assigned in such a way that it 312 represents the coordinate of the origin pixel in the actual image: the 313 overscan or pre-scan pixels must be accounted for. Putting all of 314 these element together, we can see that the pixel coordinates in the 315 camera grid may be determined from the pixel coordinates in the image 316 grid from the following relationship: 317 318 \begin{verbatim} 319 psFPA(cell,row) = psChip.cell0,row0 + psCell.cell0,row0 + psReadout.cell0,row0 + 320 psReadout.cellParity,rowParity * psReadout.cellBins,rowBins * 321 psImage.data(cell,row) 322 \end{verbatim} 323 324 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 325 326 % add psExposure to metadata? 327 % add grommit to metadata? 328 % add photsystem data to metadata? 329 % add statistics to metadata? 330 331 \subsubsection{Observatory data} 332 333 We need a container for the observatory data that doesn't change per 334 exposure. 335 336 \begin{verbatim} 337 typedef struct { 338 const char *name; ///< Name of observatory 339 const double latitude; ///< Latitude of observatory, east positive 340 const double longitude; ///< Longitude of observatory 341 const double height; ///< Height of observatory 342 const double tlr; ///< Tropospheric Lapse Rate 343 } psObservatory; 344 \end{verbatim} 345 346 The constructor for \code{psObservatory} shall be: 347 \begin{verbatim} 348 psObservatory *psObservatoryAlloc(const char *name, double latitude, double longitude, 349 double height, double tlr); 185 350 \end{verbatim} 186 351 … … 216 381 \end{verbatim} 217 382 218 \subsubsection{Observatory data}219 220 We need a container for the observatory data that doesn't change per221 exposure.222 223 \begin{verbatim}224 typedef struct {225 const char *name; ///< Name of observatory226 const double latitude; ///< Latitude of observatory, east positive227 const double longitude; ///< Longitude of observatory228 const double height; ///< Height of observatory229 const double tlr; ///< Tropospheric Lapse Rate230 } psObservatory;231 \end{verbatim}232 233 \subsubsection{Constructors}234 235 Each of the above structures needs an appropriate constructor and236 destructor. In what follows, each of the variables has the same237 meaning as in the appropriate structure.238 239 383 The constructor for \code{psExposure} shall be: 240 384 \begin{verbatim} … … 243 387 float exptime, float wavelength, const psObservatory *observatory); 244 388 \end{verbatim} 245 246 The constructor for \code{psObservatory} shall be:247 \begin{verbatim}248 psObservatory *psObservatoryAlloc(const char *name, double latitude, double longitude,249 double height, double tlr);250 \end{verbatim}251 252 The constructor for \code{psFPA} shall be:253 \begin{verbatim}254 psFPA *psFPAAlloc(int nAlloc, const psExposure *exp);255 \end{verbatim}256 The constructor shall make an empty \code{psFPA}, with the257 \code{nAlloc} allocated pointers to \code{psChip}s being set to258 \code{NULL}; all other pointers in the structure shall be initialized259 to \code{NULL}, apart from the \code{grommit}, which shall be260 constructed on the basis of the \code{exp}.261 262 The destructor for \code{psFPA} shall destroy the related263 \code{psGrommit}.264 265 The constructor for \code{psChip} shall be:266 \begin{verbatim}267 psChip *psChipAlloc(int nCells, psFPA *parentFPA);268 \end{verbatim}269 The constructor shall make an empty \code{psChip}, with the270 \code{nCells} allocated pointers to \code{psCell}s being set to271 \code{NULL}; all other pointers in the structure shall be initialized272 to \code{NULL}.273 274 The constructor for \code{psCell} shall be:275 \begin{verbatim}276 psCell *psCellAlloc(int nReadouts, struct psChip *parentChip);277 \end{verbatim}278 The constructor shall make an empty \code{psCell}, with the279 \code{nReadouts} allocated pointers to \code{psReadout}s being set to280 \code{NULL}; all other pointers in the structure shall be initialized281 to \code{NULL}.282 283 The constructor for \code{psReadout} shall be:284 \begin{verbatim}285 psReadout *psReadoutAlloc(int x0, int y0, const psImage *image);286 \end{verbatim}287 All pointers in the structure other than the \code{image} shall be288 initialized to \code{NULL}.289 290 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%291 292 \subsection{Astrometry}293 294 Astrometry is a basic functionality required for the IPP that will be295 used repeatedly, both for low-precision (roughly where is my favorite296 object?) and high-precision (what is the proper motion of this star?).297 As such, it must be flexible, yet robust. Accordingly, we will wrap298 the StarLink Astronomy Libraries (SLALib), which has already been299 developed.300 301 \subsubsection{Coordinate frames}302 \label{sec:coordinateFrames}303 304 There are five coordinate frames that we need to worry about for the305 purposes of astrometry:306 \begin{itemize}307 \item Cell: $(x,y)$ in pixels --- raw coordinates;308 \item Chip: $(X,Y)$ in pixels --- the location on the silicon;309 \item Focal Plane: $(p,q)$ in microns --- the location on the focal plane;310 \item Tangent Plane: $(l,m)$ in arcsec from the telescope boresight; and311 \item Sky: (RA,Dec) --- ICRS.312 \end{itemize}313 314 The following steps are required to convert from the cell coordinates to315 the sky:316 \begin{itemize}317 \item Cell $\longleftrightarrow$ Chip: two 2D polynomials, $(X,Y) = f(x,y)$;318 \item Chip $\longleftrightarrow$ FP: two 2D polynomials, $(p,q) = g(X,Y)$;319 \item FP $\longleftrightarrow$ TP: two 4D polynomials, $(l,m) =320 h(p,q,m,c)$, where $m$ and $c$ are the magnitude and color of the321 object, respectively; and322 \item TP $\longleftrightarrow$ Sky: SLALib transformation using a323 transform pre-computed for each pointing.324 \end{itemize}325 326 Note that the transformation between the Focal Plane and the Tangent327 Plane is a four-dimensional polynomial, in order to account for any328 possible dependencies in the astrometry on the stellar magnitude and329 color; the former serves as a check for charge transfer330 inefficiencies, while the latter will correct chromatic refraction,331 both through the atmosphere and the corrector lenses.332 333 We require structures to contain each of the above transformations as334 well as the pixel data.335 336 389 \subsubsection{SLALib information} 337 390 … … 386 439 The constructor for \code{psFixedPattern} shall be: 387 440 \begin{verbatim} 388 psFixedPattern *psFixedPatternAlloc(double x0, double y0, double xScale, double yScale, 441 psFixedPattern *psFixedPatternAlloc(double x0, double y0, 442 double xScale, double yScale, 389 443 const psImage *x, const psImage *y); 390 444 \end{verbatim} … … 396 450 elements may be derived from the size of the images. 397 451 452 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 453 454 \subsection{Astrometry} 455 456 Astrometry is a basic functionality required for the IPP that will be 457 used repeatedly, both for low-precision (roughly where is my favorite 458 object?) and high-precision (what is the proper motion of this star?). 459 As such, it must be flexible, yet robust. Accordingly, we will wrap 460 the StarLink Astronomy Libraries (SLALib), which has already been 461 developed. 462 463 \subsubsection{Coordinate frames} 464 \label{sec:coordinateFrames} 465 466 There are five coordinate frames that we need to worry about for the 467 purposes of astrometry: 468 \begin{itemize} 469 \item Cell: $(x,y)$ in pixels --- raw coordinates; 470 \item Chip: $(X,Y)$ in pixels --- the location on the silicon; 471 \item Focal Plane: $(p,q)$ in microns --- the location on the focal plane; 472 \item Tangent Plane: $(l,m)$ in arcsec from the telescope boresight; and 473 \item Sky: (RA,Dec) --- ICRS. 474 \end{itemize} 475 476 The following steps are required to convert from the cell coordinates to 477 the sky: 478 \begin{itemize} 479 \item Cell $\longleftrightarrow$ Chip: two 2D polynomials, $(X,Y) = f(x,y)$; 480 \item Chip $\longleftrightarrow$ FP: two 2D polynomials, $(p,q) = g(X,Y)$; 481 \item FP $\longleftrightarrow$ TP: two 4D polynomials, $(l,m) = 482 h(p,q,m,c)$, where $m$ and $c$ are the magnitude and color of the 483 object, respectively; and 484 \item TP $\longleftrightarrow$ Sky: SLALib transformation using a 485 transform pre-computed for each pointing. 486 \end{itemize} 487 488 Note that the transformation between the Focal Plane and the Tangent 489 Plane is a four-dimensional polynomial, in order to account for any 490 possible dependencies in the astrometry on the stellar magnitude and 491 color; the former serves as a check for charge transfer 492 inefficiencies, while the latter will correct chromatic refraction, 493 both through the atmosphere and the corrector lenses. 494 495 We require structures to contain each of the above transformations as 496 well as the pixel data. 398 497 399 498 \subsubsection{Position Finding} … … 449 548 \begin{verbatim} 450 549 psPlane *psCoordCellToChip (psPlane *out, const psPlane *in, const psCell *cell); 550 % astrometry comes from cell (no need for parent) 451 551 \end{verbatim} 452 552 which converts coordindates \code{in} on the specified \code{cell} to … … 455 555 \begin{verbatim} 456 556 psPlane *psCoordChipToFPA (psPlane *out, const psPlane *in, const psChip *chip); 557 % astrometry comes from chip (no need for parent) 457 558 \end{verbatim} 458 559 which converts the coordinates \code{in} on the specified \code{chip} … … 461 562 \begin{verbatim} 462 563 psPlane *psCoordFPAToTP(psPlane *out, const psPlane *in, float color, float mag, const psFPA *fpa); 564 % astrometry comes from FPA (no need for parent) 463 565 \end{verbatim} 464 566 which converts coordinates \code{in} on the specified focal plane … … 477 579 \begin{verbatim} 478 580 psPlane *psCoordCellToFPA(psPlane *out, const psPlane *in, const psCell *cell); 581 % astrometry comes from cell 479 582 \end{verbatim} 480 583 which performs the single-step conversion between Cell coordinates … … 483 586 \begin{verbatim} 484 587 psSphere *psCoordCellToSky(psSphere *out, const psPlane *in, float color, float mag, const psCell *cell); 588 % astrometry comes from cell,chip,fpa (PARENT IS NEEDED HERE) 485 589 \end{verbatim} 486 590 which converts coordinates on the specified cell to (RA,Dec). This … … 496 600 \begin{verbatim} 497 601 psSphere *psCoordCellToSkyQuick(psSphere *out, const psPlane *in, const psCell *cell); 602 % astrometry comes from cell (no need for parent) 498 603 \end{verbatim} 499 604 which uses the 'quick-and-dirty' transformation to convert coordinates … … 588 693 double psGetParallaxFactor(const psExposure *exp) 589 694 \end{verbatim} 590 Calculate the parallax factor for the given exposure. \tbd{Why do we 591 need this?}. 695 Calculate the parallax factor for the given exposure. \tbd{Why do we need this?}.
Note:
See TracChangeset
for help on using the changeset viewer.
