IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Ignore:
Timestamp:
Sep 12, 2005, 5:26:45 PM (21 years ago)
Author:
Paul Price
Message:

Updating for next cycle.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/doc/modules/ModulesSDRS.tex

    r4982 r5022  
    1 %%% $Id: ModulesSDRS.tex,v 1.55 2005-09-09 18:30:32 eugene Exp $
     1%%% $Id: ModulesSDRS.tex,v 1.56 2005-09-13 03:26:45 price Exp $
    22\documentclass[panstarrs]{panstarrs}
    33
    … …  
    367367DEFAULTS        METADATA
    368368        CELL.BAD                S32     0
    369         CELL.YPARITY.DEPEND     STR     CHIP.NAME
    370         CELL.YPARITY    METADATA
    371                 ccd00   S32     -1
    372                 ccd01   S32     -1
    373                 ccd02   S32     -1
    374                 ccd03   S32     -1
     369        CELL.PARITY.DEPEND      STR     CHIP.NAME
     370        CELL.PARITY    METADATA
     371                amp00   S32     1
     372                amp01   S32     -1
     373                amp02   S32     1
     374                amp03   S32     -1
    375375        END
    376376END
    … …  
    440440(for want of a better word).  These are values corresponding to
    441441general quantities and qualities relevant to the IPP such as airmass,
    442 date, read noise and filter.  These concepts are not always known by
    443 the same name, or are obtained in the same manner for all cameras, and
    444 so their source or value must be specified in the camera configuration
    445 file.  Some of these concepts make most sense to be defined at the FPA
    446 level, while others are logically defined at the cell level.
     442date, read noise and filter.  The values of each of the below concepts
     443shall be determined when the FPA is read into memory (via
     444\code{pmFPARead}), and stored at the appropriate level in the focal
     445plane hierarchy.
    447446
    448447Below is a list of concepts that the IPP requires, with the
    … …  
    450449
    451450\begin{itemize}
    452 \item \code{FPA.AIRMASS} (F32): Airmass at which the observation is made
    453   (boresight).
     451\item \code{FPA.AIRMASS} (F32): Airmass at which the observation is made (boresight).
    454452\item \code{FPA.FILTER} (STR): Filter used in observation
    455453\item \code{FPA.POSANGLE} (F32): Position angle for camera
    456 \item \code{FPA.RA}: Right Ascension of boresight
    457 \item \code{FPA.DEC}: Declination of boresight
     454\item \code{FPA.RA} (F64): Right Ascension of boresight in radians
     455\item \code{FPA.DEC} (F64): Declination of boresight in radians
    458456\item \code{FPA.RADECSYS} (STR): System of RA,Dec (e.g., J2000 or ICRS)
    459457\item \code{FPA.NAME} (STR): An identifier (e.g., observation number) for the FPA instance
    460458\item \code{CHIP.NAME} (STR): The name of the chip (unique within the FPA) --- set at FITS read
    461459\item \code{CELL.NAME} (STR): The name of the cell (unique within the parent chip) --- set at FITS read
    462 \item \code{CELL.TIME}: Time of observation start
    463 \item \code{CELL.TIMESYS}: Time system in use (e.g., UTC)
     460\item \code{CELL.TIME} (\code{psTime}): Time of observation start
    464461\item \code{CELL.READDIR} (S32): Read direction: line (1) or column (2)
    465462\item \code{CELL.BIASSEC} (STR): Overscan region(s)
    … …  
    469466\item \code{CELL.SATURATION} (F32): CCD saturation point (ADU)
    470467\item \code{CELL.BAD} (F32): CCD bad pixel point (ADU)
    471 \item \code{CELL.BINNING}: CCD Binning
    472 \item \code{CELL.PARITY} (S32): Direction of CCD readout
    473 \item \code{READOUT.EXPOSURE} (F32): Exposure time of image (sec)
    474 \item \code{READOUT.DARKTIME} (F32): Dark time for image (sec)
     468\item \code{CELL.XBIN} (S32): CCD binning in x
     469\item \code{CELL.YBIN} (S32): CCD binning in y
     470\item \code{CELL.XPARITY} (S32): Direction of CCD readout in x relative to the rest of the chip
     471\item \code{CELL.YPARITY} (S32): Direction of CCD readout in y relative to the rest of the chip
     472\item \code{CELL.EXPOSURE} (F32): Exposure time of image (sec)
     473\item \code{CELL.DARKTIME} (F32): Dark time for image (sec)
    475474\end{itemize}
    476475
    477 The value of a concept shall be found by searching in the following
    478 order:
     476\tbd{Note that \code{CELL.EXPOSURE}, \code{CELL.DARKTIME} and
     477\code{CELL.TIME} should actually be specified at the readout level.
     478However, at this present time, we're not sure how these should be
     479specified, and so we move them up to the cell level and assume that
     480all readouts are of the same exposure and dark time.}
     481
     482These concepts are not always known by the same name, nor are they
     483generally obtained in the same manner, in different camera systems,
     484and so their source or value must be specified in the camera
     485configuration file.  The value of a concept shall be found by
     486searching in the following order:
    479487\begin{itemize}
    480 \item A cache of values.
    481488\item The FITS header via the \code{TRANSLATION} table.
    482489\item The \code{DATABASE} lookup.
    483490\item The \code{DEFAULTS} value.
    484491\end{itemize}
    485 When a concept is retrieved, it shall be stored in a cache (a
    486 \code{psMetadata} within the FPA/chip/cell structures) to optimise
    487 future retrieval.  We have specified a cache and FITS header storage
    488 in the various focal plane structures for the purposes of concept
    489 retrieval.
    490 
    491 Because of the variety of methods for specifying these concepts
    492 (especially in FITS headers), we must also specify additional
    493 information in the camera configuration that specifies how to
    494 interpret the data provided. 
     492
     493After ingest, the user may safely assume that all of the above
     494concepts exist (defined at the appropriate level), is of the specified
     495type and in the specified format.
     496
     497\subsubsection{Dependencies for defaults}
    495498
    496499In the \code{DEFAULTS} table in the camera configuration, we allow the
    … …  
    516519\end{verbatim}
    517520
    518 In the FITS \code{TRANSLATION} table in the camera configuration, for
    519 certain concepts we allow the specification of the concept with an
    520 additional suffix, \code{FORMAT} which specifies the format of the
    521 FITS header.  The value is dependent upon the particular concept.
     521\subsubsection{FORMATS}
     522
     523Because of the variety of methods for specifying these concepts
     524(especially in FITS headers), we must also specify additional
     525information in the camera configuration that specifies how to
     526interpret the data provided.  These are provided in an entry
     527\code{FORMATS} (of type \code{METADATA}) in the camera configuration.
     528Within the \code{FORMATS} metadata, there is a string for each of the
     529concepts that requires a format to be specified.
    522530
    523531\paragraph{CELL.TIME}
    … …  
    537545\item \code{SEPARATE}: The date and time are specified separately, and
    538546  the \code{CELL.TIME} contains the headers for the date and the time
    539   separated by whitespace or a comma.  Then it might be necessary to
    540   add additional qualifiers to specify the formats of these:
     547  separated by whitespace or a comma.  Then it is necessary to add
     548  additional qualifiers to specify the formats of these:
    541549  \begin{itemize}
    542550  \item \code{PRE2000}: The year is in the old style two-digit format
    … …  
    554562based on someone foolishly putting the end- or mid-time in the header.}
    555563
    556 \paragraph{CELL.BINNING}
    557 
    558 The binning is usually specified in FITS headers either as separate
    559 headers for the x and the y, or in the same FITS header separated by a
    560 space or a comma.  Permitted values of \code{CELL.BINNING.FORMAT} are:
    561 
    562 \begin{itemize}
    563 \item \code{SEPARATE}: The \code{CELL.BINNING} contains the header
    564   keywords for the x and the y binning separated by whitespace or a
    565   comma.
    566 \item \code{TOGETHER}: \code{CELL.BINNING} contains the keyword for
    567   which the x and y binning are separated by whitespace and/or a
    568   comma.
    569 \end{itemize}
     564\tbd{Should we move \code{CELL.TIMESYS} into the format as well?}
    570565
    571566\paragraph{FPA.RA and FPA.DEC}
    … …  
    591586that it is in decimal format.
    592587
    593 \subsubsection{CELLS}
    594 
    595 The \code{CELLS} entry in the camera configuration contains data
    596 appropriate to each cell.  These will generally consist of the
    597 \code{CELL.BIASSEC} and \code{CELL.TRIMSEC} concepts, though it might
    598 contain \code{CELL.GAIN} and \code{CELL.READNOISE} values as well
    599 instead of going to the trouble of specifying these in the
    600 \code{DEFAULTS} with a long \code{.DEPENDS} listing.
    601 
    602 However, in some cases, we need to specify for these where the value
    603 comes from.  We declare the following rule:
     588\subsubsection{Implicit format information}
     589
     590While details like the units of the right ascension in the header must
     591be specified explicitly, some other details can be determined from
     592implicit information.
    604593
    605594\begin{itemize}
    606 \item If the type is other than \code{STR}, then the concept has that
    607   value for the cell.
    608 \item If the type is \code{STR}, then the value might potentially be
    609   confused between being a header keyword or an actual value.  For
    610   this reason, we introduce an additional concept suffix,
    611   \code{.SOURCE} (of type \code{STR}) which may be either
    612   \code{HEADER} or \code{VALUE}.
     595\item \code{FPA.RA} and \code{FPA.DEC}: if the value on ingest is of
     596type \code{STRING}, then it may be interpreted as sexagesimal
     597notation, ``\code{dd:mm:ss.ss}'', or ``\code{dd:mm.mmm}''.  A space
     598may be used instead of a colon to separate the values.  Otherwise, if
     599the value is of a numerical type (\code{F32} or \code{F64}), then that
     600is the appropriate value.
     601\item \code{CELL.XBIN} and \code{CELL.YBIN}: if the value on ingest is
     602of type \code{STRING}, then it may be interpreted as ``\code{x,y}'',
     603where \code{x} is the binning in x, and \code{y} is the binning in y.
     604A space may be used instead of a comma, and there may even be a space
     605before or after the comma (or both).  Otherwise, if the value is of a
     606numerical type (\code{S32}, etc), then that is the appropriate value.
     607\item \code{CELL.BIASSEC} and \code{CELL.TRIMSEC}: These values on
     608ingest should always be of type \code{STRING}.  If they contain a
     609square bracket, then they may be interpreted as a list of standard
     610region specifications, ``\code{[x0:x1,y0:y1];[x2:x3,y2:y3];...}'',
     611where the semi-colon may be replaced by spaces.  Otherwise, the string
     612may be interpreted as a FITS header (or headers, separated by spaces,
     613commas or semi-colons) that contains the appropriate values.
    613614\end{itemize}
    614 
    615615
    616616\subsection{Configuration APIs}
    … …  
    718718\end{verbatim}
    719719
    720 \subsubsection{Lookups}
    721 
    722 We first specify a general concept lookup function, which shall return the
    723 appropriate \code{psMetadataItem} for the value of the given \code{concept}
    724 for the specified \code{cell}, \code{chip} or \code{fpa}:
    725 \begin{prototype}
    726 psMetadataItem *pmCellGetConcept(pmCell *cell, const char *concept);
    727 psMetadataItem *pmChipGetConcept(pmChip *chip, const char *concept);
    728 psMetadataItem *pmFPAGetConcept(pmFPA *fpa, const char *concept);
    729 \end{prototype}
    730 
    731 We next specify a series of specific functions for concept lookups.
    732 These will generally be what the user utilises, so the goal is to
    733 provide a simple interface providing a single type back, so the user
    734 doesn't have to go to the trouble of checking types, etc.  These
    735 functions should employ the above three general lookup functions and
    736 deal with the result appropriately.
    737 
    738 \begin{prototype}
    739 float pmFPAGetAirmass(pmFPA *fpa);     // FPA.AIRMASS
    740 psString pmFPAGetFilter(pmFPA *fpa);   // FPA.FILTER
    741 float pmFPAGetPosAngle(pmFPA *fpa);    // FPA.POSANGLE
    742 double pmFPAGetRA(pmFPA *fpa);         // FPA.RA
    743 double pmFPAGetDec(pmFPA *fpa);        // FPA.DEC
    744 psString pmFPAGetRADecSys(pmFPA *fpa); // FPA.RADECSYS
    745 psString pmFPAGetName(pmFPA *fpa);     // FPA.NAME
    746 psString pmChipGetName(pmChip *chip);  // CHIP.NAME
    747 psString pmCellGetName(pmCell *cell);  // CELL.NAME
    748 psTime *pmCellGetTime(pmCell *cell);   // CELL.TIME
    749 psList *pmCellGetBiasSec(pmCell *cell); // CELL.BIASSEC
    750 psRegion pmCellGetTrimSec(pmCell *cell); // CELL.TRIMSEC
    751 int pmCellGetReaddir(pmCell *cell);    // CELL.READDIR
    752 float pmCellGetGain(pmCell *cell);     // CELL.GAIN
    753 float pmCellGetReadNoise(pmCell *cell); // CELL.READNOISE
    754 float pmCellGetSaturation(pmCell *cell); // CELL.SATURATION
    755 float pmCellGetBad(pmCell *cell);      // CELL.BAD
    756 psPixelCoord pmCellGetBin(pmCell *cell); // CELL.BIN
    757 psPixelCoord pmCellGetParity(pmCell *cell); // CELL.PARITY
    758 float pmReadoutGetExposure(pmReadout *readout); // READOUT.EXPOSURE
    759 float pmReadoutGetDarkTime(pmReadout *readout); // READOUT.DARKTIME
    760 \end{prototype}
    761 
    762 Most of these are straight-forward, but some need some explanation.
    763 
    764 \code{pmCellGetBiasSec} shall return a list of \code{psRegion}s, one
    765 for each bias section.
    766 
    767 \code{pmCellGetBin} shall return a \code{psPixelCoord} with the
    768 binning factors appropriately set in the \code{x} and \code{y}
    769 members.  Similarly with \code{pmCellGetParity}.
    770 
    771 
    772720\input{CameraImages.tex}
    773721
    … …  
    878826The API shall be the following:
    879827\begin{prototype}
    880 pmReadout *pmSubtractBias(pmReadout *in, void *fitSpec, const psList *overscans,
    881                           pmOverscanAxis overscanAxis, const psStats *stat,
    882                           int nBin, pmFit fit, const pmReadout *bias,
    883                           const pmReadout *dark);
     828pmReadout *pmSubtractBias(pmReadout *in, void *fitSpec, pmFit fit, bool overscan,
     829                          const psStats *stat, int nBin,
     830                          const pmReadout *bias, const pmReadout *dark);
    884831\end{prototype}
    885832
    … …  
    894841The input image may be of type U16, S32, or F32.
    895842
    896 The type of the overscan fit function, \code{fitSpec}, shall be
    897 dependent upon the value of \code{fit}, which specifies the type of
    898 fit to be employed and is described below.
    899 
    900 The prescan and/or overscan regions to be used are specified in
    901 \code{overscans}, which is a linked list of subimages.  In cases where
    902 \code{overscans} is \code{NULL} and \code{overscanAxis} is not
    903 \code{PM_OVERSCAN_NONE}, the function shall generate an error.  If
    904 \code{overscans} is non-\code{NULL} and \code{overscanAxis} is
    905 \code{PM_OVERSCAN_NONE}, then the function shall generate a warning,
    906 no overscan subtraction shall be performed, and the function shall
    907 proceed to the full-frame bias subtraction.
    908 
    909 The \code{overscanAxis} specifies how the prescan/overscan subtraction
    910 is to be performed.  It is an enumerated type:
    911 \begin{datatype}
    912 /** Overscan axis */
    913 typedef enum {
    914     PM_OVERSCAN_NONE,                   ///< No overscan subtraction
    915     PM_OVERSCAN_ROWS,                   ///< Subtract rows
    916     PM_OVERSCAN_COLUMNS,                ///< Subtract columns
    917     PM_OVERSCAN_ALL                     ///< Subtract the statistic of all pixels in overscan region
    918 } pmOverscanAxis;
    919 \end{datatype}
    920 
    921 If the \code{overscanAxis} is \code{PM_OVERSCAN_NONE}, then the
    922 function shall not perform any overscan subtraction, but proceed to
    923 the full-frame bias subtraction.  If the \code{overscanAxis} is
    924 \code{PM_OVERSCAN_ALL}, then all the overscan regions shall be used to
    925 generate a single statistic (specified by \code{stat}) which shall be
    926 subtracted from the entire image.  A warning shall be generated if the
    927 \code{overscanAxis} is \code{PM_OVERSCAN_NONE} or
    928 \code{PM_OVERSCAN_ALL} and the \code{fit} is not \code{PM_FIT_NONE}.
    929 
    930 If the \code{overscanAxis} is \code{PM_OVERSCAN_ROWS} or
    931 \code{PM_OVERSCAN_COLUMNS}, then the overscan shall be reduced to a
    932 single vector (in the specified dimension) using the specified
    933 statistic (\code{stat}).
     843Overscan subtraction is controlled by the \code{overscan} boolean.  If
     844it is \code{true}, then overscan subtraction is performed.  The
     845prescan and/or overscan regions to be used are specified in
     846\code{in->bias} (a linked list of subimages).  These shall be reduced
     847to a single vector (in the dimension specified by \code{CELL.READDIR},
     848which is accessed via the parent of the \code{pmReadout}).
     849
     850If the overscan is not defined for each row/column, then the function
     851shall generate a warning and then interpolate using the provided
     852functional form if \code{fit} is not \code{PM_FIT_NONE} (see below);
     853otherwise, the function shall generate an error.
    934854
    935855The statistic to use in combining multiple pixels in the
    … …  
    941861according to the following priority order: \code{PS_STAT_SAMPLE_MEAN},
    942862\code{PS_STAT_SAMPLE_MEDIAN}, \code{PS_STAT_CLIPPED_MEAN},
    943 \code{PS_STAT_ROBUST_MEAN},\ \code{PS_STAT_ROBUST_MEDIAN},
     863\code{PS_STAT_ROBUST_MEAN}, \code{PS_STAT_ROBUST_MEDIAN},
    944864\code{PS_STAT_ROBUST_MODE}.
    945865
    946866If \code{nBin} is positive and less than the size of the vector, then
    947 the vector shall subsequently be binned into bins that are a relative
    948 size of \code{nBin} compared to the original pixels, again using the
    949 specified statistic (\code{stat}).  If \code{fit} is
    950 \code{PM_FIT_SPLINE}, then \code{nBin} also serves as the number of
    951 spline pieces.
    952 
    953 \code{fit} is an enumerated type:
     867the vector shall subsequently be binned into \code{nBin} bins, using
     868the specified statistic (\code{stat}).  For example, the whole
     869overscan region can be taken as a unity if \code{nBin=1}.  If
     870\code{fit} is \code{PM_FIT_SPLINE}, then \code{nBin} also serves as
     871the number of spline pieces.
     872
     873\code{fit} is an enumerated type which specifies the type of fit to
     874employed on the overscan vector (and hence the type of \code{fitSpec}):
    954875\begin{datatype}
    955 /** Fit types */
    956876typedef enum {
    957877    PM_FIT_NONE,                        ///< No fit
    … …  
    961881\end{datatype}
    962882
    963 If \code{fitSpec} is \code{NULL}, or \code{fit} is \code{PM_FIT_NONE},
    964 then no fit shall be performed to the overscan.  Otherwise,
    965 \code{fitSpec} shall be interpreted to be a structure of the
     883If \code{fit} is \code{PM_FIT_POLYNOMIAL} or \code{PM_FIT_SPLINE},
     884then \code{fitSpec} shall be interpreted to be a structure of the
    966885appropriate type (\code{psPolynomial1D} for \code{PM_FIT_POLYNOMIAL},
    967886and \code{psSpline1D} for \code{PM_FIT_SPLINE}), and the overscan
    968 shall (after reduction of the vector and binning) be fit using the
    969 specified functional form.  Upon return, the \code{fitSpec} shall
    970 contain the coefficients of the overscan fit.  If \code{fit} is
    971 \code{PM_FIT_SPLINE}, then the \code{fitSpec} may be \code{NULL},
    972 in which case a new \code{psSpline} is allocated; in any case, the
    973 number of spline pieces shall be set to \code{nBin}.
    974 
    975 If the overscan is not defined for each row/column, then the function
    976 shall generate a warning and then interpolate using the provided
    977 functional form if \code{fit} is not \code{PM_FIT_NONE}; otherwise,
    978 the function shall generate an error.
    979 
    980 Following any binning, the vector shall be fit by the functional form
    981 specified by \code{fit}.  Then the overscan shall be subtracted from
    982 the image, using values from the fit if \code{fit} is not
    983 \code{PM_FIT_NONE}; otherwise using values from the overscan vector if
    984 \code{overscanAxis} is not \code{PM_OVERSCAN_ALL}; otherwise using the
    985 appropriate statistic applied to all the prescan/overscan pixels.
    986 
    987 A bias image shall be subtracted pixel-by-pixel from the input image
    988 if \code{bias} is non-NULL.  A dark image, multiplied by the
    989 \code{darkTime}, shall be subtracted pixel-by-pixel from the input
    990 image if \code{dark} is non-NULL.  Note that the input image,
     887vector shall be fit using the specified functional form.
     888
     889In cases where \code{fitSpec} is \code{NULL} and \code{fit} is not
     890\code{PM_FIT_NONE} or \code{overscan} is \code{true}, the function
     891shall generate an error.  If \code{overscan} is \code{false} and
     892\code{fit} is not \code{PM_FIT_NONE}, then the function shall generate
     893a warning, and no overscan subtraction shall be performed.  Upon
     894return, the \code{fitSpec} shall contain the coefficients of the
     895overscan fit.
     896
     897If \code{fitSpec} is \code{NULL}, or \code{fit} is \code{PM_FIT_NONE},
     898then no fit shall be performed to the overscan.
     899
     900A bias frame shall be subtracted pixel-by-pixel from the input image
     901if \code{bias} is non-NULL.  If \code{dark} is non-\code{NULL}, then
     902the dark image, scaled by the ratio of dark times (from
     903\code{CELL.DARKTIME}) shall be subtracted pixel-by-pixel from the
     904input image.  Note that the input image,
    991905\code{in}, and the \code{bias} and \code{dark} frames need not be the
    992906same size, but the function shall use the offsets in the image
    … …  
    999913images may be copied to the same type as the input image if required.
    1000914
    1001 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     915%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1002916
    1003917\subsection{Non-linearity}
    … …  
    1037951type U16, S32, or F32.
    1038952
     953%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     954
    1039955\subsection{Flat-fielding}
    1040956
    1041957Given an input image and a flat-field image, \code{pmFlatField} shall
    1042958divide the input image by the flat-field image and return it in place,
    1043 updating the mask as appropriate.  The API shall be the following:
    1044 \begin{prototype}
    1045 bool pmFlatField(pmReadout *in, pmReadout *mask, const pmReadout *flat);
     959updating the mask contained within the input image as appropriate.
     960The API shall be the following:
     961\begin{prototype}
     962bool pmFlatField(pmReadout *in, const pmReadout *flat);
    1046963\end{prototype}
    1047964
    … …  
    1071988is left to the caller.  This function is basically equivalent to a
    1072989divide (with \code{psImageOp}), but with care for the region that is
    1073 divided, checking for negative pixels, and copying of the mask from
    1074 the \code{flat} to the output.
    1075 
    1076 The input and flat-field images must both be of type F32.
    1077 
    1078 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     990divided, checking for zero and negative pixels, and copying of the
     991mask from the \code{flat} to the output.
     992
     993The images in the input and flat-field readouts must both be of type
     994F32.
     995
     996%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1079997
    1080998\subsection{Masking}
    … …  
    11211039the \code{growVal}).
    11221040
    1123 \tbd{In the future, may change grow to a convolution kernel}.
     1041\tbd{In the future, may change \code{grow} to a convolution kernel}.
    11241042
    11251043Note that the input image, \code{in}, and the \code{mask} need not be
    … …  
    11361054
    11371055\subsection{Subtract sky}
     1056
     1057\tbd{This may be deferred.}
    11381058
    11391059Given an input image, a polynomial or spline specifying the order of a
    … …  
    35033423\end{document}
    35043424
     3425%%% All this is here for storage only --- it's not part of the document.
     3426
     3427
    35053428\subsection{Cosmic rays}
    35063429
    … …  
    36483571\code{in}.
    36493572
     3573%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     3574
     3575\subsection{Fixed Pattern}
     3576
     3577The fixed pattern is a correction to the general astrometric solution
     3578formed by summing the residuals from many observations.  The intent is
     3579to correct for higher-order distortions in the camera system on a
     3580coarse grid (larger than individual pixels, but smaller than a single
     3581cell).  Hence, in addition to the offsets, we need to specify the size
     3582and scale of the grid in $x$ and $y$, as well as the origin of the
     3583grid.
     3584
     3585\begin{datatype}
     3586typedef struct {
     3587    int nX;                             ///< Number of elements in x
     3588    int nY;                             ///< Number of elements in y
     3589    double x0;                          ///< Position of 0,0 corner on focal plane
     3590    double y0;                          ///< Position of 0,0 corner on focal plane
     3591    double xScale;                      ///< Scale of the grid
     3592    double yScale;                      ///< Scale of the grid
     3593    double **x;                         ///< The grid of offsets in x
     3594    double **y;                         ///< The grid of offsets in y
     3595} psFixedPattern;
     3596\end{datatype}
     3597
     3598The constructor for \code{psFixedPattern} shall be:
     3599\begin{prototype}
     3600psFixedPattern *psFixedPatternAlloc(double x0,        double y0,
     3601                                    double xScale,    double yScale,
     3602                                    const psImage *x, const psImage *y);
     3603\end{prototype}
     3604Here, \code{x0}, \code{y0}, \code{xScale} and \code{yScale} have the
     3605same meaning as in the \code{psFixedPattern} structure.  Note that the
     3606values of the fixed pattern offsets are specified as images, the
     3607values from which need to be copied into the \code{double **x} and
     3608\code{double **y} of \code{psFixedPattern}, and that the number of
     3609elements may be derived from the size of the images.
     3610
     3611\tbd{Usage of this type is not clear, and awaits prototyping --- do not
     3612worry about coding this in detail yet.}
     3613
Note: See TracChangeset for help on using the changeset viewer.