Changeset 7783

Timestamp:

Jun 30, 2006, 7:18:07 PM (20 years ago)

Author:

eugene

Message:

updates

Location:

trunk/doc

Files:

• design/ippSSDD.tex (modified) (2 diffs)
• modules/CameraImages.tex (modified) (2 diffs)
• psphot/scheme.sxi (modified) ( previous)

trunk/doc/design/ippSSDD.tex

@@ -10 +10 @@
 \project{Pan-STARRS Image Processing Pipeline}
 \organization{Institute for Astronomy}
-\version{DR.02}
+\version{00}
 \docnumber{PSDC-430-014}
 
@@ -24 +24 @@
 DR.01     & 2006.01.19 & First draft release to CDR committee \\ \hline
 DR.02     & 2006.01.22 & Second draft release to CDR committee \\ \hline
+00        & 2006.04.26 & First version release after CDR report \\ \hline
 \RevisionsEnd
 

trunk/doc/modules/CameraImages.tex

@@ -417 +417 @@
 
 \subsection{Input/Output of a Focal Plane Hierarchy}
+
+Data sources and output targets may be specified in the Camera
+Configuration file.  These targets may consist of explicitly named
+files, or they may define rules by which the names are constructed,
+using other information available to the configuration system.  The
+following function provides a mechanism with which the name rules are
+selected and interpretted
+\begin{prototype}
+char *pmConfigNameFromRule (char *rule, psMetadata *camera, *psMetadata *arguments, psMetadata *header);
+\end{prototype}
+
+The \code{rule} defines a name in the \code{camera} metadata.  The
+rule defines the output value of a new name.  The rule may include
+elements which are looked up from the camera configuration
+information, the supplied command-line arguments, or the header of the
+current file.  The following lookups rules are define:
+\begin{verbatim}
+{CELL.NAME} : pmCell.concepts:CELL.NAME
+{CHIP.NAME} : pmChip.concepts:CHIP.NAME
+{EXTNAME}   : value of EXTNAME in header
+{INPUT}     : value of INPUT from camera config
+{OUTPUT}    : value of OUTPUT from camera config
+\end{verbatim}
+
 
 We specify two functions to construct a focal plane hierarchy from a
@@ -1194 +1218 @@
 psArray pmAstromFitDistortion (pmFPA *fpa, psArray *gradients, psMetadata *config);
 \end{prototype}
+
+\section{FPA Files}
+
+The FPA structure defines the layout of the data read from a camera.
+It contains elements to specify the location of the pixels within the
+focal plane structure.  It also provides the relationship between a
+specific hardware layout of the pixels (readouts, cells, chips, etc)
+and a specific organization model for the data (headers and pixel
+array sections, etc).  Depending on the needs of the users or the
+desires of the instrument builders, the data read out from a single
+camera may be stored in a number of different ways.  For example,
+multiple cells within the same chip may be stored within the same
+pixel array in different locations, within separate arrays in the same
+FITS file in different extensions, or as separate files.  Multple
+chips may be written to the same file or different files.  Multiple
+readouts may be separate files or slices of an image cube.  
+
+The pmFPA structure does not (and should not) define the relationship
+between the pixel data and the actual files files on disk.  
+
+The pmFPAfile structure defines a relationship between the data stored
+in a pmFPA structure and an external (file) representation of that
+data.  The purpose of this structure and its supporting functions is
+to allow the application designer to easily add or changes the data
+sources and the data destinations used by an application.  The
+pmFPAfile defines the input and output data formats.  A single
+pmFPAfile may represent FITS image data files, jpeg image files,
+photometric measurements, astrometric calibrations, etc.  Each
+instance of a pmFPAfile is identified with a particular data format.
+It is defined as a data source (file from which to read data) or a
+data destination (file to be written).  The pmFPAfile also defines the
+naming conventions to be used for the particular type of file or set
+of files.  A single pmFPAfile may be used to represent data coming
+from or going to a single file on disk or a collection of files on
+disk.  The pmFPAfile also defines anciliary data which is needed for
+some file formats and not for others.  For example, FITS file
+extensions need to be given particular EXTNAME values.  Or, jpeg
+images require a colormap and clipping rules. 
+
+The pmFPAfile system also lets the application designer have
+flexibility with which types of files are required within a particular
+program.  Consider an application which performs some manipulation of
+an image.  The program may call several analysis modules as it
+operates on the data.  For example, it may perform a bias subtraction
+on the image pixels data.  Or, it may detect objects within another
+module.  The pmFPAfile system allows the author of a module to refer tperform The program may have a few