There are two options for describing input images. Either: List the image file names Or: provide an ascii file with the file names listed, one per record.
Output tiepoint table. This is an ASCII table with a header, a record indicating the number of tiepoints, then a series of records, one per tiepoint. Values in the record are: laft_image, right_image, left_sample, left_line, right_sample, right_line, corrected_sample, corrected_line, quality, interactive_flag
Corrected navigation filename. If marsnav was run on the input images it created a table of corrected pointing parameters. If you refer to this table using NAVTABLE it will override the pointing parameters (e.g. azimuth and elevation) in the picture labels, giving you a better registered mosaic.
The vicar image band number. Defaults to 1
Correlation size. Must be an odd number. Defaults to 15 square. Window can be specified via a single value, which applies to both line and sample directions. Or, it may be specified as a pair: (line,samp), in order to define a rectangular window.
Initial correlation search area. Must be an odd number. Defaults to 199 square. See "Correlate all tiepoints". Window can be specified via a single value, which applies to both line and sample directions. Or, it may be specified as a pair: (line,samp), in order to define a rectangular window.
Minimum acceptable correlation quality for amoeba8 step. See "Correlate all tiepoints".
The width of a border all around the image to avoid in selecting pixels for correlation. Also is the width added to the template area all around to permit rotation of the template. See "Define a candidate tiepoint grid".
The busyness threshold. Any correlation area must have a business above BUSY to be correlated. See "Compute a busyness metric".
Spacing for initial tiepoint grid. See "Define a candidate tiepoint grid". The grid spacing is optinally adjusted by the ratio between the nominal and actual heights of the images (see NOMINAL_HEIGHT).
Maximum separation angle for image pairs. Current best values are 60 for MER navcam, and 20 for MER pancam. See "Reject pairs that are too far apart".
Specifies how close the point can be to the center or edge of the search window during dynamic search window tuning. See "Correlate all tiepoints".
Specifies how much to adjust the search window during dynamic search window tuning. See "Correlate all tiepoints".
Minimum search window size. Used for three things: 1) How close the search window can be to the image edge. See "Define a candidate tiepoint grid". 2) Initial search window when there are no tiepoints. See "Use minimum search window and correlate again". 3) Minimum size of search window during dynamic adjustment. See "Correlate all tiepoints".
Maximum size of search window during dynamic adjustment. See "Correlate all tiepoints".
Size of window used for calculatiny busyness metric. See "Compute a busyness metric".
Quality threshold for linear correlation. See "Correlate all tiepoints".
File to use specifying rover mask. See "Filter out points on the rover". The format of this XML file is the same as that used for MARSFILTER; see the help for MARSFILTER for details.
Enables use of rover mask. See "Filter out points on the rover".
Controls how many tiepoints to keep per image pair, based on the size of the area covered by the tiepoints. See "Geometric scatter of points". The density is optionally adjusted by the ratio between the nominal and actual heights of the image (see NOMINAL_HEIGHT).
Maximum # of iterations for geometric scatter step. See "Geometric scatter of points".
Weighting factor for center of image in geometric scatter. See "Geometric scatter of points".
Window size for parameter filtering. See "Filter tiepoints based on correlator parameters".
The value must be within this many sigmas during parameter filtering. See "Filter tiepoints based on correlator parameters".
Minimum sigma value for parameter filtering, below which sigma checks are not used and the point is passed. See "Filter tiepoints based on correlator parameters".
Maximum absolute difference value from mean for parameter filtering. See "Filter tiepoints based on correlator parameters".
Flag to enable debug prints and files. See the "TUNING" section in the main help. 0 == no debug 1 == info about window sizes, culling 2 == 1 + info about tiepoints and param filtering 3 == 2 + saving intermediate (temp) images (don't do w/more than 1 or 2 pairs!)
Starting key number for the tiepoint file (XML format only). Tiepoint files contain a list of images, each of which is associated with an integer key. Setting START_KEY to some value allows tiepoint files to be merged easily, without the keys conflicting. It is acceptable to have the same image in different sections of a merged file (with different keys); they are properly merged when read in.
There are two tiepoint file formats: "old" is the simple text-based list, as used for most of MER, while "xml" is an XML-based format that supports additional tiepoint types. The FORMAT parameter controls which one to use. Over time the use of "old" should be phased out and eventually the FORMAT parameter will disappear.
Specifies the nominal height of an input image. If specified, the GRID_SPACING and DENSITY parameters are assumed to apply to an image of this height. The parameters are then scaled based on the actual image height. This allows the grid spacing and density to have similar effect across the inputs, when the input images are at different resolutions. For example, when including a thumbnail image, a density setting that would produce 3 tiepoints along the edge of a nominally-sized image will still produce 3 tiepoints on the thumbnail. The parameter is option, but highly recommended when mixing resolutions. Without this, the grid spacing might be larger than an entire thumbnail.
Specifies which image (if any) are reference images. Reference images are not tiepointed to each other. They are tiepointed to non-reference images. The use case is where you have a mosaic that has already been tiepointed that is being used as a control network for a new mosaic of the same area. These frames will be set to references when running marsnav/marsnav2 meaning they will not be adjusted. Because they won't be adjusted, there is no point in collecting tiepoints between them. Although these tiepoints don't hurt per se, they do take time to compute and file space to manage. So turning them off is more efficient. We do tie reference to non-reference images as this is needed for them to work as a control network. If a number in the list is negative, it means all images from the previous number through (the absolute value of) this one will be references. For example a list: 1,3,-6,8,11,-15 will cause the following images to be reference images: 1,2,4,5,6,8,11,12,13,14,15 Numbering of images starts at 1.
Overrides the FOV limit for projection. Normally this is the H + V FOV of the camera, but limited to the range 30-90 degrees. This parameter overrides that value (after the limits, so it can be anything). The projected vector has to be within this of the center projection of the camera. Currently A is used as a proxy for this, which causes issues with some camera models where A through C does not project to the middle of the image.
Turns on or off parallel processing. The default is on. The main help describes some environment variables that can further control parallel processing. Note that this program uses standard OpenMP (which is built in to the gcc/g++ compilers), so further details can be found in the OpenMP documentation.
The local mars surface normal vector coordinate system specified by SURF_COORD parameter (defaults to surface fixed). For most pan/tilt cameras, if the lander is not tilted this vector would be: normal=(0,0,-1). ie: x_component=0, y_component=0, z_component=-1. This need not be a unit vector. This vector is used to define the surface plane to which image points are projected in order to minimize parallax. For SPHERE1/2 surface models, normal's first parameter is used to denote sphere's radius. Thus to describe sphere of radius R, user would specify normal=(R, 0, 0).
Any point on the surface, in coordinate system specified by SURF_COORD parameter
(defaults to surface fixed). This defines where the tilted plane is in space.
Although any point may be used, normally the point just "under" the origin is selected.
Defaults:
Mars Pathfinder: (0.0, 0.0, 0.0) (lander zero point is on the ground)
Mars 98 Lander: (0.0, 0.0, 1.64) (lander zero point is on top of deck)
MER : (0.0, 0.0, 0.294)
For MER images taken on top of the lander, the ground is roughly at (0.0, 0.0, 0.7)
For SPHERE1/2 surface models, GROUND parameter is used to denote sphere's
center.
The coordinate system that surface parameters like GROUND and NORMAL are defined in. For valid values refer to COORD parameter description. The interpretation of the values is dependent on the mission. Defaults to surface fixed coordinate system. Note that no validation is done for input strings because COORD is using the same values. So user needs to be extra careful in specifying SURF_COORD value. For example COORD=local would be correctly interpreted to mean LOCAL_LEVEL because of validation process. On the other hand specifying SURF_COORD=local would lead to underlying code treating the input value as invalid and reverting to default which is FIXED frame. So the values for SURF_COORD should be spelled exactly as found in the list of valid values for COORD parameter.
The type of mars surface to use. The surface is used to intercept view rays emanating from the cameras in order to model out parallax between the stereo cameras. The two options are surface=INFINITY which means no surface is used or surface=PLANE (the default case). If surface=PLANE then the plane is defined by the NORMAL and GROUND parameters. For the cases when PLANE doesn't match local topography sufficiently well, here are two sphere surface models: surface=SPHERE1 and surface=SPHERE2. SPHERE1 is useful to model convex surfaces like hills, it returns closest(first) ray-surface intersection point. SPHERE2 is useful to model concave surfaces, like crater when the camera point is outside looking in, it returns farthest(second) ray-surface intersection point. For the case when camera is inside the sphere surface, like rover sitting in the crater, there is only a single intersection point and SPHERE1 and SPHERE2 behave exactly the same. Last, MESH is a surface model defined by a mesh file (.obj) which path is given with SURF_MESH.
Mesh OBJ file to use as the surface model. For the mesh to be used, SURFACE must be set to MESH. The coordinates of the mesh vertices can be expressed in any CS. However the mesh CS must be supplied via SURF_CSFILE. If SURF_CSFILE is not used, then the mesh is assumed to be to the CS that results from COORD or SURF_COORD VARI SURF_CSFILE File name of a vicar file whose CS (contained in the labels) will be read and assigned to the SURFACE model. The type of image and its content are of no interest, we are just reading the CS. That CS will supersede any other surface CS definition (COORD or SURF_COORD). Its typical use is to supply a CS to a given mesh file (expectedly the XYZ from which the mesh is computed from, but doesn't have to). But SURF_CSFILE could be use to define a CS in which NORMAL and GROUND for a PLANE surface are expressed in.
A colon-separated list of directories in which to look for configuration and calibration files. Environment variables are allowed in the list (and may themselves contain colon-separated lists). The directories are searched in order for each config/cal file when it is loaded. This allows multiple projectes to be supported simultaneously, and allows the user to override any given config/cal file. Note that the directory structure below the directories specified in this path must match what the project expects. For example, Mars 98 expects flat fields to be in a subdirectory named "flat_fields" while Mars Pathfinder expects them to be directly in the directory specified by the path (i.e. no intermediate subdirectories).
Specifies a mission-specific pointing method to use. Normally this parameter is not used, in which case the "default" pointing methods are used. Some missions may have special, or alternate, pointing methods available, which are indicated by this string (for example, backlash models, using arm joint angles instead of x/y/z/az/el, etc). A substring search is used, so multiple methods (where that makes sense) can be specified by separating the keywords with commas. Note that nav files created using one pointing method will most likely not be compatible with a mosaic created using a different pointing method. The methods available vary per mission, but some methods available at the time of this writing are: BACKLASH : Mars 98 SSI only. Selects a backlash pointing model, which adjusts the telemetered azimuth and elevation values based on knowledge of the camera's mechanical backlash and the direction the motor was travelling when the image was taken.
Specifies a method for pointing corrections. Loose method matches with pointing parameters of the image. Tight method matches with unique id of the image.
Tolerance value for matching pointing parameters in the pointing corrections file. Used if MATCH_METHOD=LOOSE Default value is pretty arbitrary, though seems to work well so far....
Disables all label-derived parameters to the Site mechanism which underlies coordinate systems. This forces all sites to be identical, with all rotations and offsets set the same. In the case of MPF or Mars 98, this disables the lander quaternion and offset (sets them to identity and 0, respectively). This option should not be used with images taken from different vantage points (e.g. the spacecraft moved, or mixing a lander and a rover) or invalid results will be obtained. The use of this option invalidates the Fixed coordinate frame; any values reported in the Fixed frame will not correctly reflect the orientation of the lander/rover. Obviously, this option should be rarely used; it is intended for when the image labels defining the site are invalid or inconsistent.
Rover State File. This is a list of filenames to load containing Rover State information. These files contain position and orientation information for a rover (or other mobile spacecraft) at various sites. They are in XML format. See the "Rover Motion Counter (RMC) Master File SIS" for details on these files. Rover State Files have a priority order. The files listed first have the highest priority. Environment variables may be used in the list. For MER, if a directory is specified, then that directory is searched for RMC Master files and any found are loaded. The directory structure and filename convention is covered in the RMC SIS. The directory specified is the one containing "master", so if <dir> is the name specified in the RSF parameter, the following files will be searched for: <dir>/master/_Master.svf <dir>/master/ _Site_ _Master.rvf The name of each file loaded is printed to the stdout log for reference.
If enabled, this causes the internal database of RMC locations to be printed out to the stdout log. This is after the RSF files have been loaded and the coordinate systems read from the input label(s).
This parameter is ignored by marstie. It is here for compatibility with subroutines used by other programs (see e.g. marsmap).
This parameter is ignored by marstie. It is here for compatibility with subroutines used by other programs (see e.g. marsmap).
Specifies which major Site is the "Fixed" Site for this run.
Historically, MPF and M98 had a single "Surface Fixed" frame which never
moved, and which all other coordinate system frames were referenced to.
With the advent of long-range rovers (such as MER and FIDO), that became
insufficient. The rover traverses far enough that errors in knowledge of
coordinate system offset and orientation become unacceptable.
For this reason, a system of major Sites was introduced. Periodically
during the mission, a Site frame is declared. This then becomes the
reference frame for all activities until the next Site is declared.
References are kept local, and errors don't propogate across Sites.
However, if images from more than one Site are combined together, the
Site's must be placed relative to each other. Therefore a single reference
frame is still needed to combine different sites.
The FIXED_SITE parameter controls which of the major Site frames is
the reference ("fixed") site for this program run. This fixed frame
can vary in different program runs, but is constant throughout one
execution.
If not specified, FIXED_SITE defaults to the minimum Site number (i.e.
lowest numbered, or earliest chronologically) used in all input images.
Normally this default is sufficient; rarely must FIXED_SITE be specified.
One or more Rover State Files must usually be specified in order to combine
image from more than one Site. These describe the relationship between
sites. See the RSF parameter.