The INP parameter is used to name the input files that make up the mosaic. It is only needed if -INPUT is specified. As with all similar programs, 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.
Input mosaic. As of this writing, it must be in cylindrical projection (vertical and poar will be supported later), and have appropriate (MER-style) labels describing the projection. Projection parameters may be overridden.
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. Note that if NAVTABLE was used when initially creating the mosaic, it should be specified for this program as well.
Input file containing coordinates. The file formats are described in the main help.
Output file continaining translated coordinates. The file formats are described in the main help. If this filename is not given, no file output will be done.
Input coordinate specified directly via parameter. This is simply a list of numbers, two per coordinate (in the case of INPUT coordinates, 3 per coordinate).
Output coordinates via parameters. These can be accessed via the normal VICAR output parameter mechanisms (v2param). Note that coordinates are only output here if -USE_PARM is specified.
Type of coordinates to use for the translation. One is always MOSAIC coordinates. The other may be either INPUT or PROJECTION coordinates, and that is specified by this parameter. INPUT is the default.
Specifies whether the translation is being done FROM mosaic coordinates, or TO them. FROM_MOSAIC is the default.
When doing MOSAIC->INPUT transforms (-INPUT -FROM_MOSAIC), the result can be ambiguous, as multiple inputs can overlap the same pixel. With the default SINGLE, only the first overlapping input is reported. If -MULTI is specified, all overlapping inputs are reported (on the same line). Note that use of -MULTI with -USE_PARM and OUT_COORDS should be avoided, as it will be ambiguous which outputs map to which inputs. If this is needed, specify only one input coordinate.
Specifies whether or not coordinates are output to the OUT_COORDS parameter. THe default is not to, for efficiency reasons.
Specifies whether or not to print the transforms to the terminal screen (stdout). The default is to print.
Specifies which of two similar file formats to use. In either case, coordinates are listed one per line. For the default FLAT, that's all that is in the file. For -TWOLAYER, there are additional counts of coordinates first. See the main help for details.
Override for the input mosaic scale in pixels/degree. Defaults to the scale from the mosaic label. NOTE: THIS IS FOR CYLINDRICAL AND POLAR ONLY. See VERT_SCALE for Vertical projection.
Override for the azimuth of the left edge of the input mosaic. Defaults to the azimuth from the mosaic label. Cylindrical only.
Override for the azimuth of the right edge of the input mosaic. Defaults to the azimuth from the mosaic label. Cylindrical only.
Override for the elevation of the top of the input mosaic. Defaults to the elevation from the moasaic label. Used for both Cylindrical and Polar (unlike the other az/el limits).
Override for the elevation of the bottom of the input mosaic. Defaults to the elevation from the mosaic label. Cylindrical only.
Overrides the center of projection. This is an XYZ point from which all of the azimuth/elevation rays emanate. It defaults to the origin from the mosaic label. Cylindrical, Polar only.
Overrides the azimuth at the top of the image. This has the effect of rotating the image, with the given azimuth being straight up. It defaults to the azimuth from the mosaic label. Polar only.
Overrides the input mosaic scale in meters/pixel for Vertical projections only. (See SCALE for Cylindrical and Polar). It defaults to the scale from the mosaic label.
Overrides the maximum extent of the image in meters in the X direction (up, or north). The picture height is from -MAXX to +MAXX. Defaults to the value from the mosaic label.
Overrides the maximum extent of the image in meters in the Y direction (right, or east). The picture width is from -MAXY to +MAXY. Defaults to the value from the mosaic label.
The local mars surface normal vector in the coordinate system specified by SURF_COORD. It defaults to thevalue from the mosaic label. 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 the sphere's radius. Thus to describe sphere of radius R, the user would specify NORMAL=(R, 0, 0).
Any point on the surface, in the coordinate system specified by SURF_COORD (defaults to surface fixed coordinates). This defines where the tilted plane is in space. Although any point may be used, ideally the point just "under" the origin is selected. Defaults to the value from the mosaic label; this is an override. For SPHERE1/2 surface models, the GROUND parameter is used to denote the sphere's center.
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 options are surface=INFINITY which means no surface is used, 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. This is an override for the value taken from the mosaic label.
The coordinate system that surface parameters like GROUND and NORMAL are defined in. For valid values refer to the COORD parameter description. Defaults to the value taken from the mosaic label. Note that no validation is done for input strings because COORD is using the same values. So the user needs to be extra careful in specifying SURF_COORD values. For example, COORD=local would be correctly interpreted to mean LOCAL_LEVEL because of the validation process. On the other hand, specifying SURF_COORD=local is not valid and would revert to the default. So the values for SURF_COORD should be spelled exactly as found in the list of valid values for COORD.
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 matchs with pointing parameters of the image. Tight method matchs with unique id of the image.
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).
The coordinate system to use for the mosaic input parameters. The default
is taken from the mosaic; this is an override. Note that it can be dangerous
to override this without also overriding all the mosaic projection parameters
(and possibly even then).
The interpretation of the values of COORD is dependent on the mission.
Some representative missions are listed here:
Fixed - The Fixed frame (default). This is the ultimate reference frame
(see also FIXED_SITE for rover missions).
Instrument - The "natural" frame for the instrument (of the first input
image). MPF: Lander or Rover; M98: MVACS; MER: Rover.
Site - A major Site frame. For rover missions, COORD_INDEX specifies which
Site frame to use. Non-rover missions treat this as Fixed.
Rover - An instance of the Rover frame. For rover missions, COORD_INDEX
specifies which instance of the rover frame to use. Non-rover mission
use the spacecraft frame (e.g. Lander for M98).
Local_Level - An instance of a Local Level frame. This is typically
coincident with the Rover frame (in XYZ) but oriented toward North
like the Site and Fixed frames. For MER, this is an instance of a
Drive index move.
The index specifies which instance of a coordinate system to use. It is currently applicable only to rover-based missions, but could have other uses. The index is equivalent to the Rover Motion Counter (RMC) for MER and FIDO. For MER/FIDO, there are many Site frames. Each is numbered with a single index. For Site Frames, coord_index specifies which to use. Likewise, there are many Local_Level and Rover frames, corresponding to values of the RMC. The multiple instances of this frame are selected by COORD_INDEX. Generally COORD_INDEX defaults sensibly so you don't usually need to specify it. It will default to the instance used by the first input.
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.
Specifies which solution ID to use for pointing corrections. There are potentially many different definitions for the same coordinate system. These are identified via a unique Solution ID. If this parameter is given, only the specified solution's definition is searched for.