IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Ignore:
Timestamp:
Nov 26, 2004, 3:48:23 PM (22 years ago)
Author:
eugene
Message:

work on astrom / coord transforms

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/doc/pslib/psLibSDRS_Astrom.tex

    r1674 r2502  
    99additional metadata to describe the data in detail.  Second, astronomy
    1010applications frequent involve multiple, related images.  For
    11 PanSTARRS, and for general astronomical applications, we require a
     11Pan-STARRS, and for general astronomical applications, we require a
    1212richer collection of data structures which describe a very general
    1313image concept.  We have defined several layers in the hierarchy which
    1414are necessary to describe the image data which will be produced by the
    15 PanSTARRS Gigapixel cameras as well as other standard astronomical
     15Pan-STARRS Gigapixel cameras as well as other standard astronomical
    1616images. 
    1717
    … …  
    1919imaging.  If we consider various optical and IR array cameras, a
    2020single 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
     21measurements which is well represented as a single 2D image.  We
     22define our lowest-level astronomical image structure,
     23\code{psReadout}, to contain the pixels produced by a single readout
     24of the detector, along with metadata needed to define that readout:
     25the origin and binning of the image relative to the original detector
     26pixels explicitly in the structure, and pointers to the general
     27metadata and derived objects, if any.
     28
     29A single detector may be read multiple times in sequence.  For
     30example, infrared detectors frequently produce an image immediately
     31after the detector is reset followed by an image after the basic
     32exposure is complete.  Both readouts correspond to the same pixels,
     33though the binning or rastering may be different between the two
     34readouts.  Another example is the video sequence produced by the
     35Pan-STARRS Gigapix camera guide cells, each of which represents a
    3536series of many images from a subraster of pixels in the detector
    3637readout portion.  The second level of our image container hierarchy,
    … …  
    3839detector.
    3940
    40 In the PanSTARRS Gigapix camera, the basic readout region is a
     41In the Pan-STARRS Gigapix camera, the basic readout region is a
    4142fraction of the full imaging area of a single CCD chip.  The chip is
    4243divided into 64 cells, any fraction of which may have been readout
    … …  
    5960the focal plane consists of these eight chips.
    6061
    61 As another example, consider an observation by PS1.  The focal plane
     62As another example, consider an observation by PS-1.  The focal plane
    6263would consist of 60 chips, each of which consist of 64 cells (or less;
    6364a few cells may be dead).  Some cells (those containing guide stars
    … …  
    7677has one \code{psCell}, which in turn has one \code{psReadout}. 
    7778
    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}
     79The data structures defined below provide two additional features
     80beyond the hierarchy of relationships.  First, each level of the
     81hierarchy includes a generic \code{psMetadata} pointer to provide
     82whatever metadata would be appropriate for that level.  The functions
     83within PSLib do not specify the contents of those metadata containers.
     84One example of their usage is provided in the documentation for the
     85Pan-STARRS IPP collection of data processing modules. 
     86
     87While the \code{psMetadata} pointers provide a mechanism to carry
     88generic information about the image, the hierarchy of data structures
     89also provides an explicit set of information defining the geometrical
     90relationships between the levels of the hierarchy.  Two types of
     91information are provided.  In the first case, basic offsets (and in
     92the case of the readouts, binning and flips) are defined to specify
     93the location of a given \code{psCell} with respect to its containing
     94\code{psChip} in the assumption that the pixels in the entire focal
     95plane array are laid out on a uniform grid.  This is a crude
     96approximation, and cannot be assumed for careful astrometric analysis,
     97but it can be used as a starting point or to place the the pixels in a
     98test image.  For higher precision, detailed astrometric
     99transformations between one frame and the next are also provided.
     100
     101\tbd{in the future, it may be worthwhile to migrate all of these
     102additional pieces to the psMetadata since there is no pressing need to
     103have them visible in the data structures}
     104
     105\subsubsection{Image Data Container Hierarchy}
     106
     107\subsubsubsection{A Readout}
    83108
    84109A readout is the result of a single read of a cell (or a portion
    … …  
    90115\begin{verbatim}
    91116typedef 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
    92121    const unsigned int colBins;        ///< Amount of binning in x-dimension
    93122    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.
    96123    psImage* image;                    ///< imaging area of Readout
    97     psList*  objects;                  ///< objects derived from Readout
    98124    psMetadata* metadata;              ///< readout-level metadata
    99125} psReadout;
    100126\end{verbatim}   
    101127
    102 \subsubsection{A Cell}
     128The constructor for \code{psReadout} shall be:
     129\begin{verbatim}
     130psReadout *psReadoutAlloc();
     131\end{verbatim}
     132All pointers in the structure shall be initialized to \code{NULL}.
     133
     134\subsubsubsection{A Cell}
    103135
    104136A cell consists of one or more readouts (usually only one except in the
    … …  
    119151\begin{verbatim}
    120152typedef struct {
     153    const int col0;                    ///< Offset from the left of chip.
     154    const int row0;                    ///< Offset from the bottom of chip.
    121155    psArray* readouts;                 ///< readouts from the cell
    122156    psMetadata* metadata;              ///< cell-level metadata
    … …  
    124158    psPlaneTransform* toFPA;           ///< transformations from cell to FPA coordinates
    125159    psPlaneTransform* toSky;           ///< transformations from cell to sky coordinates
    126     struct psChip* parent;             ///< chip in which contains this cell
     160    psChip *parent;
    127161} psCell;
    128162\end{verbatim}
    129163
    130 \subsubsection{A Chip}
     164The constructor for \code{psCell} shall be:
     165\begin{verbatim}
     166psCell *psCellAlloc(int nReadouts, struct psChip *parentChip);
     167\end{verbatim}
     168The 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
     171shall 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
     174to \code{NULL}. All other pointers in the structure shall be
     175initialized to \code{NULL}.
     176
     177\subsubsubsection{A Chip}
    131178
    132179A chip consists of one or more cells (according to the number of
    … …  
    141188\begin{verbatim}
    142189typedef struct {
     190    const int col0;                    ///< Offset from the left of FPA.
     191    const int row0;                    ///< Offset from the bottom of FPA.
    143192    psArray* cells;                    ///< cells in the chip
    144193    psMetadata* metadata;              ///< chip-level metadata
    145194    psPlaneTransform* toFPA;           ///< transformation from chip to FPA coordinates
    146195    psPlaneTransform* fromFPA;         ///< transformation from FPA to chip coordinates
    147     struct psFPA* parent;              ///< FPA which contains this chip
     196    psFPA *parent;
    148197} psChip;
    149198\end{verbatim}
    150199
    151 \subsubsection{A Focal Plane}
     200The constructor for \code{psChip} shall be:
     201\begin{verbatim}
     202psChip *psChipAlloc(int nCells, psFPA *parentFPA);
     203\end{verbatim}
     204The 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}
    152213
    153214A focal plane consists of one or more chips (according to the number
    … …  
    176237    psFixedPattern* pattern;           ///< fixed pattern residual offsets
    177238    const struct psExposure* exposure; ///< information about this exposure
    178     const psGrommit* grommit;          ///< grommit allows conversion from tangent plane to sky
     239    const psGrommit* grommit;          ///< grommit allows conversion from tangent plane to sky
    179240    psPhotSystem* colorPlus;           ///< Color reference
    180241    psPhotSystem* colorMinus;          ///< Color reference
    … …  
    183244    float chi2;                        ///< chi^2 of astrometric solution
    184245} psFPA;
     246\end{verbatim}
     247
     248The constructor for \code{psFPA} shall be:
     249\begin{verbatim}
     250psFPA *psFPAAlloc(int nChips, const psExposure *exp);
     251\end{verbatim}
     252The 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
     261Two utility functions are defined to manage the collection of
     262backward-pointing links:
     263\begin{verbatim}
     264bool psFPASetLinks (psFPA *fpa);
     265bool psFPATestLinks (psFPA *fpa);
     266\end{verbatim}
     267The first of these functions constructs the \code{parent} pointers for
     268all entries in a \code{psFPA} structure.  The second structure checks
     269the 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
     279These container levels also include in their definition the
     280information needed to transform the coordinates in one of the levels
     281to the coordinate system relevant at the higher levels.
     282
     283The data structures define the basic coordinate relationships between
     284all of these data elements.  A set of offsets for each level in the
     285data hierarchy specifies the location of the particular set of pixels
     286in the next level of the hierarchy.  This is illustrated in
     287Figure~\ref{CameraLayout}.  These offsets may be used to define the
     288complete camera layout in the approximating assumption that all pixels
     289in the camera are laid out on a single linear pixel grid.  This
     290approximate is sufficient for many basic operations.  For more detail,
     291the precise astrometric relationship between each level of the
     292hierarchy may also be made available in the metadata of the data
     293structures.
     294
     295In practice, a single readout from a detector may represent only a
     296subset of the complete set of pixels addressed by the {\it cell}.  The
     297readout may also have binning applied in both of the two dimensions.
     298There may also be overscan and pre-scan regions in the set of pixels.
     299Finally, the readout direction is not always the same for all detector
     300amplifiers.  As shown in Figure~\ref{CameraLayout}, these different
     301concepts are represented in the data hierarchy.  The coordinate of the
     302origin of the data grid for one level of the hierarchy in the grid of
     303the containing hierarchy is defined for each data level.  For example,
     304the origin of the coordinates for a single chip are located in the
     305camera grid at \code{psChip.cell0,row0}.  The \code{psReadout} data
     306level has additional information to specify the details of the readout
     307process.  The elements \code{psReadout.colParity,rowParity} specify
     308the parity of the specific readout (readout direction), while the
     309elements \code{psReadout.colBins,rowBins} specify the binning factor
     310in the two dimensions.  Note that the value of
     311\code{psReadout.col0,row0} must be assigned in such a way that it
     312represents the coordinate of the origin pixel in the actual image: the
     313overscan or pre-scan pixels must be accounted for.  Putting all of
     314these element together, we can see that the pixel coordinates in the
     315camera grid may be determined from the pixel coordinates in the image
     316grid from the following relationship:
     317
     318\begin{verbatim}
     319psFPA(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
     333We need a container for the observatory data that doesn't change per
     334exposure.
     335
     336\begin{verbatim}
     337typedef 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
     346The constructor for \code{psObservatory} shall be:
     347\begin{verbatim}
     348psObservatory *psObservatoryAlloc(const char *name, double latitude, double longitude,
     349                                  double height, double tlr);
    185350\end{verbatim}
    186351
    … …  
    216381\end{verbatim}
    217382
    218 \subsubsection{Observatory data}
    219 
    220 We need a container for the observatory data that doesn't change per
    221 exposure.
    222 
    223 \begin{verbatim}
    224 typedef struct {
    225     const char *name;                   ///< Name of observatory
    226     const double latitude;              ///< Latitude of observatory, east positive
    227     const double longitude;             ///< Longitude of observatory
    228     const double height;                ///< Height of observatory
    229     const double tlr;                   ///< Tropospheric Lapse Rate
    230 } psObservatory;
    231 \end{verbatim}
    232 
    233 \subsubsection{Constructors}
    234 
    235 Each of the above structures needs an appropriate constructor and
    236 destructor.  In what follows, each of the variables has the same
    237 meaning as in the appropriate structure.
    238 
    239383The constructor for \code{psExposure} shall be:
    240384\begin{verbatim}
    … …  
    243387                            float exptime, float wavelength, const psObservatory *observatory);
    244388\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 the
    257 \code{nAlloc} allocated pointers to \code{psChip}s being set to
    258 \code{NULL}; all other pointers in the structure shall be initialized
    259 to \code{NULL}, apart from the \code{grommit}, which shall be
    260 constructed on the basis of the \code{exp}.
    261 
    262 The destructor for \code{psFPA} shall destroy the related
    263 \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 the
    270 \code{nCells} allocated pointers to \code{psCell}s being set to
    271 \code{NULL}; all other pointers in the structure shall be initialized
    272 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 the
    279 \code{nReadouts} allocated pointers to \code{psReadout}s being set to
    280 \code{NULL}; all other pointers in the structure shall be initialized
    281 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 be
    288 initialized to \code{NULL}.
    289 
    290 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    291 
    292 \subsection{Astrometry}
    293 
    294 Astrometry is a basic functionality required for the IPP that will be
    295 used repeatedly, both for low-precision (roughly where is my favorite
    296 object?) and high-precision (what is the proper motion of this star?).
    297 As such, it must be flexible, yet robust.  Accordingly, we will wrap
    298 the StarLink Astronomy Libraries (SLALib), which has already been
    299 developed.
    300 
    301 \subsubsection{Coordinate frames}
    302 \label{sec:coordinateFrames}
    303 
    304 There are five coordinate frames that we need to worry about for the
    305 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; and
    311 \item Sky: (RA,Dec) --- ICRS.
    312 \end{itemize}
    313 
    314 The following steps are required to convert from the cell coordinates to
    315 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 the
    321 object, respectively; and
    322 \item TP $\longleftrightarrow$ Sky: SLALib transformation using a
    323 transform pre-computed for each pointing.
    324 \end{itemize}
    325 
    326 Note that the transformation between the Focal Plane and the Tangent
    327 Plane is a four-dimensional polynomial, in order to account for any
    328 possible dependencies in the astrometry on the stellar magnitude and
    329 color; the former serves as a check for charge transfer
    330 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 as
    334 well as the pixel data.
    335 
    336389\subsubsection{SLALib information}
    337390
    … …  
    386439The constructor for \code{psFixedPattern} shall be:
    387440\begin{verbatim}
    388 psFixedPattern *psFixedPatternAlloc(double x0, double y0, double xScale, double yScale,
     441psFixedPattern *psFixedPatternAlloc(double x0,        double y0,
     442                                    double xScale,    double yScale,
    389443                                    const psImage *x, const psImage *y);
    390444\end{verbatim}
    … …  
    396450elements may be derived from the size of the images.
    397451
     452%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     453
     454\subsection{Astrometry}
     455
     456Astrometry is a basic functionality required for the IPP that will be
     457used repeatedly, both for low-precision (roughly where is my favorite
     458object?) and high-precision (what is the proper motion of this star?).
     459As such, it must be flexible, yet robust.  Accordingly, we will wrap
     460the StarLink Astronomy Libraries (SLALib), which has already been
     461developed.
     462
     463\subsubsection{Coordinate frames}
     464\label{sec:coordinateFrames}
     465
     466There are five coordinate frames that we need to worry about for the
     467purposes 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
     476The following steps are required to convert from the cell coordinates to
     477the 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) =
     482h(p,q,m,c)$, where $m$ and $c$ are the magnitude and color of the
     483object, respectively; and
     484\item TP $\longleftrightarrow$ Sky: SLALib transformation using a
     485transform pre-computed for each pointing.
     486\end{itemize}
     487
     488Note that the transformation between the Focal Plane and the Tangent
     489Plane is a four-dimensional polynomial, in order to account for any
     490possible dependencies in the astrometry on the stellar magnitude and
     491color; the former serves as a check for charge transfer
     492inefficiencies, while the latter will correct chromatic refraction,
     493both through the atmosphere and the corrector lenses.
     494
     495We require structures to contain each of the above transformations as
     496well as the pixel data.
    398497
    399498\subsubsection{Position Finding}
    … …  
    449548\begin{verbatim}
    450549psPlane *psCoordCellToChip (psPlane *out, const psPlane *in, const psCell *cell);
     550% astrometry comes from cell (no need for parent)
    451551\end{verbatim}
    452552which converts coordindates \code{in} on the specified \code{cell} to
    … …  
    455555\begin{verbatim}
    456556psPlane *psCoordChipToFPA (psPlane *out, const psPlane *in, const psChip *chip);
     557% astrometry comes from chip (no need for parent)
    457558\end{verbatim}
    458559which converts the coordinates \code{in} on the specified \code{chip}
    … …  
    461562\begin{verbatim}
    462563psPlane *psCoordFPAToTP(psPlane *out, const psPlane *in, float color, float mag, const psFPA *fpa);
     564% astrometry comes from FPA (no need for parent)
    463565\end{verbatim}
    464566which converts coordinates \code{in} on the specified focal plane
    … …  
    477579\begin{verbatim}
    478580psPlane *psCoordCellToFPA(psPlane *out, const psPlane *in, const psCell *cell);
     581% astrometry comes from cell
    479582\end{verbatim}
    480583which performs the single-step conversion between Cell coordinates
    … …  
    483586\begin{verbatim}
    484587psSphere *psCoordCellToSky(psSphere *out, const psPlane *in, float color, float mag, const psCell *cell);
     588% astrometry comes from cell,chip,fpa (PARENT IS NEEDED HERE)
    485589\end{verbatim}
    486590which converts coordinates on the specified cell to (RA,Dec).  This
    … …  
    496600\begin{verbatim}
    497601psSphere *psCoordCellToSkyQuick(psSphere *out, const psPlane *in, const psCell *cell);
     602% astrometry comes from cell (no need for parent)
    498603\end{verbatim}
    499604which uses the 'quick-and-dirty' transformation to convert coordinates
    … …  
    588693double psGetParallaxFactor(const psExposure *exp)
    589694\end{verbatim}
    590 Calculate the parallax factor for the given exposure.  \tbd{Why do we
    591 need this?}.
     695Calculate the parallax factor for the given exposure.  \tbd{Why do we need this?}.
Note: See TracChangeset for help on using the changeset viewer.