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 image containing the mosaic. By default, the output will have the same number of bands as the input with the most bands, and all bands will be processed. Inputs with fewer than that many bands repeat their last band, so bw and color images can be mixed. If BAND is specified, the output will have a single band.
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 output projection type. Options include CYLINDRICAL (the default), POLAR, VERTICAL, and SINUSOIDAL.
The zoom factor for the image. This is a shortcut to computing and specifying SCALE or VERT_SCALE. A zoom of 2 will make the image twice as big as it "naturally" wants to be (or twice as big as the specified SCALE/VERT_SCALE). A zoom of .25 will make it one quarter the "natural" size.
The BSQ input file band number. Defaults to all bands in image, but will use a value of 1 if an invalid band is specified. Providing a value will cause only that band to be processed.
The range of inputs to actually mosaic. Normally all inputs are mosaicked. However, if this parameter is specified, all inputs will be used to calculate the output projection, but only the inputs in the specified range will be mosaicked. This allows the generation of a large mosaic to be spread out over several nodes on a network, with a program like FASTMOS used to combine all the outputs together. Note that any underlays (annotation that goes under the image) should be put on the *last* mosaic only for FASTMOS; overlays (that show on top of everything) should be on all images (or at least the first). The input numbers are 1-based. If only one number is specified, it is the starting number; the end defaults to the # of inputs.
Specifies values to multiply DN values of each input picture. Defaults to 1.0 for each picture. For example, if there are five input images, then try BIAS=(1.0, 1.33, 0.8, 1.90, 1.0) BIAS is obsolete now; it has been replaced by BRTCORR.
Specifies an input file containing brightness corrections. This is an XML file that comes from a program like marsbrt which contains correction factors for each image. These factors may be additive or multiplicative constants to be applied to the image, or other corrections that may be implemented in the future. The BRTCORR mechanism is intended to replace BIAS. Using them together should be avoided because the labels will not reflect both (the BIAS overrides). If you do, however, the BRTCORR corrections are applied to the data first, before BIAS.
The output mosaic scale in pixels/degree. Defaults to the natural scale of the camera. This natural scale is printed out for reference. NOTE: This is for Cylindrical, Polar, and Sinusoidal only. See VERT_SCALE for Vertical projection.
Azimuth of the left edge of the output mosaic. Defaults to the smallest azimuth of any corner or edge-center of the input images. Cylindrical and Sinusoidal only.
Azimuth of the right edge of the output mosaic. Defaults to the largest azimuth of any corner or edge-center of the input images. Cylindrical and Sinusoidal only.
Elevation of the top of the output mosaic. Defaults to the largest elevation of any corner or edge-center of the input images. Used for Cylindrical and Sinusoidal as well as Polar (unlike the other az/el limits).
Elevation of the bottom of the output mosaic. Defaults to the smallest elevation of any corner or edge-center of the input images. Cylindrical and Sinusoidal only.
Overrides the center of projection. This is an XYZ point from which all of the azimuth/elevation rays emanate. It defaults to the average of all the input camera locations. Note that the coordinate frame used to express this value is usually the projection frame (COORD) but can be modified using PO_COORD. This allows you to, for example, specify the origin in a constant location relative to the rover (in rover frame, say at the mast rotation point) while making the mosaic in site or local_level coordinates. Cylindrical, Polar, Sinusoidal only.
Coordinate frame used to specify PROJ_ORIGIN. If not given, the frame defaults to that given in COORD. This parameter is ignored unless PROJ_ORIGIN is specified.
Overrides the azimuth at the top of the image. This has the effect of rotating the image, with the given azimuth being straight up. Polar only.
The output mosaic scale in meters/pixel for Vertical projections only. (See SCALE for Cylindrical and Polar). There is no "natural" default for this parameter, so it arbitrarily defaults to .01 meters/pixel.
Specifies the minimum extent of the image in meters in the X direction (down, or south). The picture height is from MINX to MAXX. Defaults to -MAXX which mimics the behavior before MINX was available.
Specifies the maximum extent of the image in meters in the X direction (up, or north). The picture height is from MINX to MAXX. Defaults to 5 meters.
Specifies the minimum extent of the image in meters in the Y direction (down, or south). The picture height is from MINY to MAXY. Defaults to -MAXY which mimics the behavior before MINY was available.
Specifies the maximum extent of the image in meters in the Y direction (right, or east). The picture width is from MINY to MAXY. Defaults to 5 meters.
Azimuth of the center of the sinusoidal projection. This is the azimuth at which the "cusps" (where the zenith and nadir converge) appear. Defaults to the center of the mosaic. Sinusoidal only.
Elevation of the center of the sinusoidal projection. This is the elevation from which the cosine terms are measured. So anything at this elevation will be full-scale (just like Cylindrical). The azimuth scale changes as a function of the cosine of the angle between the point's elevation and the center elevation. In essense, this defines where the "equator" of the projection is. Defaults to 0 degrees. Sinusoidal only.
WRAP_AZ is an optional argument used to define a specific wrapping location for a mosaic. It is only used for a complete 360 mosaic, if the mosaic is not full the wrap should occur where the data is missing. Can be defined in any coordiante system with WRAP_CS. Input in degrees.
Needed for supporting the functionality of WRAP_AZ in converting coordinate systems. The default value of 0 is sufficient for the vast majority of use cases.
Coordinate system of the WRAP_AZ input. This is helpful if you would like to define a wrapping location in a coordinate system different than your other mosaic parameters. An example of this functionality would be wrapping in the rover frame at WRAP_AZ=180 (back of the rover) to move the rover hardware to the edges of the mosaic.
Specifies the type of grid to use. Valid values are:
NOGRID - No grid is generated
GRID - A grid is generated "underneath" the image, so it shows only where
there is no image
GRID_OVERLAY - A grid is generated "on top of" the image, so it shows
everywhere.
GRID_LABELS - Plots the numbers and text only, without the grid lines.
Useful when combined with INPUT_RANGE.
The grid consists of azimuth/elevation lines (Cylindrical, Polar), or
X/Y lines (Vertical) and labels for each line along the edges (down from
the center for Polar Elevation).
The default is GRID.
See also GRID_SPACING, GRID_DN, and GRID_ZOOM.
Overrides the spacing of the grid lines. Both sets of lines use the same value (i.e. azimuth and elevation can't be different). See the GRID keyword. Defaults to 10 degrees for Cylindrical and Polar, and 1 meter for Vertical.
The DN to use for the grid and grid labels. See GRID keyword. Note, a GRID_DN of 0 is transparent (i.e. ignored). If the number of DN's supplied is less than the number of bands, the last value is repeated as necessary.
The zoom factor to use for the grid labels (i.e. how big the text is). Must be a positive integer, 1 is the smallest possible. See the GRID keyword.
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 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. 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.
Causes the program to place an ASCII number into the mosaic at the center of where each input picture falls. Numbers begin at 1 and increase in the order of the filenames in the input. This permits one to determine which picture populated which part of the mosaic. Defaults to NONUMBER. The DN to use for the numbers is set by NUMBER_DN, and the zoom factor for the numbers by NUMBER_ZOOM. Normally numbers are written in order, 1 to n (or, NUMBER_START to n). However, this is not quite right per the stacking order, which puts the first on top. If multiple images stack, -NUMBER will show the highest number while the imagery is from the lowest. This is fixed by -INV_NUMBER. Specifying -INV_NUMBER is the same as -NUMBER except they're plotted in the opposite order... bottom to top. The result is the top image "wins", just as with the mosaic. In a perfect world, this would be the default, but there's enough history with the current behavior of -NUMBER to be hesitant to change it.
The DN to use for the image numbers. See NUMBER keyword. Note, a NUMBER_DN of 0 is transparent (i.e. ignored). If the number of DN's supplied is less than the number of bands, the last value is repeated as necessary.
The zoom factor to use for the image numbers (i.e. how big the numbers are). Must be a positive integer, 1 is the smallest possible. See NUMBER keyword.
Specifies the starting point for the image numbers (i.e. the first input is assigned this number for the image number overlays, and they increment from there). Normally this will be 1, but could be set differently if only part of a larger mosaic is being generated.
Causes "footprints" to be drawn around each input image in the output
mosaic. This is useful to show overlap of the images, and is often used
in conjunction with NUMBER.
There are three values:
NOFOOTPRINT - No footprint is displayed. This is the default.
FOOTPRINT - Shows the footprint only where the edge of the image is "on top".
Useful to see which image is laid down first. If the DN (FOOT_DN) has
insufficient contrast, the footprint may not be very visible, since it
is interpolated like normal pixels.
OVERLAP - shows the entire footprints of all images, even if another image
overlaps the edge of the input. Useful to see how much overlap there is
between images. OVERLAP mode will slow down the program down somewhat,
since the borders are drawn in after the mosaic is created (to ensure that
all borders are drawn).
The DN to use for the footprints is set by FOOT_DN. Note that the footprint
replaces (hides) the outer row of pixels in the image.
The DN to use for the footprints. See FOOTPRT keyword. Note, a FOOT_DN of 0 is transparent (i.e. ignored). If the number of DN's supplied is less than the number of bands, the last value is repeated as necessary.
Normally, if footprints or image numbers are turned on, all images will get them. This parameter allows you to specify a maximum image number for footprints and numbers. Any images beyond this image number will not get footprints or image numbers. This can be useful if you want to include "background" images in the mosaic that are not numbered (such as for a finder chart). Just put those images at the back of the file list.
Tau is a measure of atmospheric opacity. The default for normal Mars conditions is 0.6. Higher tau means more dust in the atmosphere.
Keyword paramter that selects radiometric correction mode of the input images. RAD (the default) enables the correction (for missions/instruments which support it); NORAD disables it; ZENITH_SCALED_RAD the radiometry you'd get if the sun were at zenith on a clear day. The scaling factor is a combination of solar elevation and tau, and will have the effect of brightening up images that were taken near sunset.
DN scaling factor. This factor is used to convert between physical radiometric units (watts/(meter**2, steradian, micron)) and DN's for the output mosaic. The formula is: true_radiance = offset + (factor * DN) where "offset" is 0.0 in the current implementation, and "factor" is 1.0 / DNSCALE (making the formula equivalently: offset + (DN / DNSCALE)). The offset and factor (1.0/DNSCALE) are written to the output mosaic label.
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).
Three-state keyword parameter to control whether or not to apply scaling parameters to reconstruct floating point values. RESCALE says to do the conversion, and reconstitute the float based on the RADIANCE_* keywords. Note that if there are no RADIANCE_* keywords, this is a no-op, so it doesn't hurt to turn this on for non-scaled images. NOSCALE says to not to the conversion. This is what we do now. If your inputs are dynamically scaled, you'll probably get surprising results. AUTOSCALE says to figure it out based on the DNSCALE_OUT parameter (see DNSCALE_OUT for details) and -ZENITH_SCALED_RAD flag. If DNSCALE_OUT is STATIC, then it is NOSCALE; if DNSCALE_OUT is DYNAMIC/IDENTIT or RAD=ZENITH_SCALED_RAD, then it is RESCALE.
Three-state keywork parameter to scale output DN values. If -STATIC is enabled, then the value specified by DNSCALE will be used as the DN scaling factor (note the unit scaling factor as well) for all radiometric models supplied. If -DYNAMIC is enabled, then the maximum responsivity value across all radiometric models will be used as the DN scaling factor (note the unit scaling factor as well). If -IDENTITY is enabled, then no scaling will be applied.
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....
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. Values useful to marsmap: BORDER_LEFT: Specifies, in pixels, a border to cut off on the left side of each input image. This can be used to eliminate edge effects in input images. BORDER_RIGHT: Same but for the right side. BORDER_TOP: Same but for the top edge. BORDER_BOTTOM: Same but for the bottom edge. New ones (as of 2012/10/26) not mentioned elsewhere: RMC_MAX_INDEX: Specifies the max # of indices to use when comparing RMC's. Effectively makes the RMC only this long. Useful to ignore pose changes due to IMU jitter, or when using the RSF file. Default is 10. RMC_EPSILON: Epsilon value for comparison of coordinate system values. Even if the RMC's match, a new CS is created if the values differ by more than this epsilon. Setting it high means more CS's will considered equal. Default: 1e-3 MARGIN_LEFT: Like BORDER_LEFT, but the margin is scaled based on the downsample factor of the image. So if the margin is needed to hide CCD defects, the same area of the CCD will be cut off regardless of downsampling. MARGIN_RIGHT, MARGIN_TOP, MARGIN_BOTTOM: Same as above.
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.
MARSMAP can operate in one of two modes. The first is the traditional method (INCREMENTAL), where each line is written to the mosaic output file as it is processed. The second (MEMORY) is the default; it stores the entire mosaic in memory and writes it to the file only when it is complete.
Keyword parameter that turns on or off interpolation of the output images pixel values. INTERP (the default) enables the interpolation, while NOINTERP disables it. MEMORY mode (the default) is somewhat faster (perhaps 10%, although that's highly variable), and is required if doing parallel processing. However, the memory requirements could become prohibitive for large mosaics. INCREMENTAL mode is slower, but has the advantage of being able to view the mosaic as it is being generated. An image viewer such as xvd can be used to monitor the progress of the mosaic. By reloading periodically, one can do quality control while a long mosaic is in progress. Also, the memory requirements are drastically lower in this mode.
Overrides the default limits (89.4, 30) on size of the FOV for the input image. The FOV really affects how far away from the pointing vector we can be before we say nope, this image doesn't apply. The actual FOV is calculated, but these limits exist as sanity checks. Note that the limit is input in degrees, with the larger value first. If either limit is specified, both must be.
If -REVERSE is turned on, the program will stack the outputs in reverse order, with last on top instead of first on top. This is implemented inefficiently in that we still go through the list in top-down order, but we just don't stop once a pixel is found. So every input that overlaps is mosaicked to the output, and the last one survives. Note that this is exactly what OVR does, but intentionally rather than as a side effect.
Turns on or off parallel processing using OMP, which uses multiple cores on a single host machine. 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 DATA_SET_NAME typically identifies the instrument that acquired the data, the target of that instrument, and the processing level of the data. This value is copied to the output label, property IDENTIFICATION, keyword DATA_SET_NAME.
The DATA_SET_ID value for a given data set or product is constructed according to flight project naming conventions. In most cases the DATA_SET_ID is an abbreviation of the DATA_SET_NAME. This value is copied to the output label, property IDENTIFICATION, keyword DATA_SET_ID.
When a data set is released incrementally, such as every three months during a mission, the RELEASE_ID is updated each time part of the data set is released. For each mission(or host id if multiple spacecrafts), the first release of a data set should have a value of "0001". This value is copied to the output label, property IDENTIFICATION, keyword RELEASE_ID.
Specifies a permanent, unique identifier assigned to a data product by its producer. Most commonly, it is the filename minus the extension. This value is copied to the output label, property IDENTIFICATION, keyword PRODUCT_ID.
Specifies the unique identifier of an entity associated with the production of a data set. This value is copied to the output label, property IDENTIFICATION, keyword PRODUCER_ID.
Specifies the identity of a university, research center, NASA center or other institution associated with the production of a data set. This value is copied to the output label, property IDENTIFICATION, keyword PRODUCER_INSTITUTION_NAME.
Specifies a target. The target may be a planet, satelite, ring, region, feature, asteroid or comet. This value is copied to the output label, property IDENTIFICATION, keyword TARGET_NAME.
Specifies the type of a named target. This value is copied to the output label, property IDENTIFICATION, keyword TARGET_NAME.
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 all input parameters and output values,
and the mosaic itself. The interpretation of the values 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.
Overrides what CS type is allowed for the FIXED frame
Overrides what CS type is allowed for the fixed frame. Normally this is the lowest-numbered SITE_FRAME. However, the PIG library actually looks for any CS with only one index as a potential fixed frame. This causes issues with the M20 helicopter, where e.g. the HELI_G_FRAME also has only one index. This parameter allows the user to force the fixed frame to SITE_FRAME.
Specifies which solution ID to use for pointng 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.
Input tiepoint file for tiepoint visualization. Only used if TIE_TYPE is turned on. Both the old (text) and new (XML) tiepoint file formats are supported, and the format is auto-detected.
Allows tiepoints to be visualized by plotting them on top of a mosaic. Should never be used for production mosaics; this is intended to help determine if tiepoints (such as from MARSAUTOTIE) are any good. The default value, NO_TIES, turns off tiepoint visualization completely. POINTS turns on point mode. The left side of the tiepoint is indicated by a dot (single pixel) on the image at the location that point projects to. The value of the pixel is TIE_DN plus 10 times the difference (in mosaic space) between the left and right parts of the tiepoint. This gives some indication of how well the tiepoint was corrected. Thus if TIE_DN is 7000, a value of 7032 indicates that the tiepoints were 3.2 pixels apart. Of course, a difference of 0 (dn=7000 for this example) means that the tiepoint was corrected perfectly. FLAG does what POINTS does, but then draws an additional vector on the image (at half the intensity of the point). This vector starts at the point and continues for 10 pixels parallel to a line between the centers of the "left" and "right" images for that tiepoint. Thus it provides some indication of which pair of images was involved in the tiepoint, when there are multiple overlapping images. Note that the edge of the mosaic is not considered; if the image centers are on opposite ends of the mosaic (as in, the edge of the mosaic splits the centers), the vector will use the actual centers, without being adjusted for wrapping. VECTOR does what POINTS does, but then draws an additional vector on the image (at half the intensity of the point). This vector starts at the point and continues in the direction of the right-side tiepoint. The length of the vector is 10 times the difference between the left and right (same as the intensity of the point itself). This makes it easy to visualize tiepoint outliers. TRUE_VECTOR acts the same but without the 10x length modification (so the endpoints lay exactly where the two parts of the tiepoint project to). Tiepoint visualization is especially effective when combined with -NUMBER and -OVER (overlapping footprints). The -FLAG or -VECTOR modes should almost always be used; POINT alone has not proved to be useful.
DN value to use for tiepoint visualization. See TIE_TYPE. If the number of DN's supplied is less than the number of bands, the last value is repeated as necessary.
Specifies a cutoff elevation above which no output is generated. This is generally useful only in overlap mode. In overlap mode, this provides a way to eliminate the sky from consideration when determining brightness statistics for the overlaps. This can be helpful when (as is often the case) the sky exhibits different radiometry than the ground. Cutting off the sky better matches the ground in these cases. HORIZON is only active for cylindrical and polar projections. It is ignored for vertical.
Turns on overlap mode, and specifies the output overlap file. Overlap mode computes statistics for the overlapping areas in the mosaic, and outputs a file containing those statistics. This file can then be used by "marsbrt" to compute a correction. This overlap mode replaces the functionality of the old "marsint" program.
Specifies the number of images for each pass. Normally this is 20 (or the maximum for overlap mode). Generally this will not need to be adjusted, but if the last pass has only one or two images, you may get better throughput by increasing this parameter slightly. Each pass has an overhead, so if memory is sufficient, a large value can also increase throughput. In overlap mode, all images must fit into memory; therefore MAX_OPEN needs to be at least as big as the number of input images. The default is 20 for normal mode, and the maximum number of images for overlap mode.
Starting key number for the output overlap file. Overlap files contain a list of images, each of which is associated with an integer key. Setting START_KEY to some value allows overlap 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.
Specifies the maximum size of overlap areas. 0 means no maximum.
Specifies whether to create normal overlaps, overall "overlaps" (whole-image statistics), or both.
Turns on HSI mode for overlaps.
Specifies the (optional) output filename for the index file. The index file contains, for each pixel, a halfword integer (16 bit signed) identifying which image the pixel came from. 0 indicates no value (black in the mosaic). Numbers from 1-n match the order of files in the input list file (or INP parameter, if a list file isn't given). For most mosaics, the file could be converted to byte using CFORM (half is used to support more than 255 input files).
Specifies the (optional) output filename for the ICM file. The ICM file is an Image Coregistration Map. It is a two-band float file containing the line, sample coordinate of the input pixel used for the point. This is the same basic format as correlation maps such as MARSCOR3 produces, except that multiple images are involved (thus the need for the index file, in IDX_OUT).
Turns on scale bar. The scale bar is by default plotted in the lower left corner (see BAR_POS). The nominal size of the bar (really the minimum size) in pixels is given by BAR_SIZE. The bar size will be increased as necessary to achieve round units. The bar size is constrained to be 1, 2, 5, or 10 per decade, and units are nm, um, mm, cm, m, and km (units are plotted in upper case, however). So the possible bar sizes are quantized, for example sizes can be: ..., 0.01NM, 0.02NM, 0.05NM, 0.1NM, 0.2NM, 0.5NM, 1nm, 2nm, 5nm, 10nm, 20nm, 50nm, 100nm, 200nm, 500nm 1um, 2um, 5um, 10um, 20um, 50um, 100um, 200um, 500um 1mm, 2mm, 5mm, 1cm, 5cm, 10cm, 20cm, 50cm, 1m, 2m, 5m, 10m, 20m, 50m, 100m, 200m, 500m, 1km, 2km, 5km, 10km, ... A critical factor in proper scale bar size is the range. The meters per pixel is determined by range / scale where scale is the pixels/degree (converted to pixels/radian) from the SCALE parameter or as determined by the input camera model. The scale is correct for the mosaic, so the accuracy of the scale bar depends on the range. Normally range is computed by projecting to the surface model. However, this can be quite inaccurate if the actual ground does not match the surface model. For that reason, it is recommended that the range be supplied (via BAR_RANGE) when possible. This may come from an XYZ image, or (for example for MSL ChemCam or M20 SuperCam RMI) from the known focus distance. If the range is not computable for a given point (for example it projects above the surface model), or if it would plot off the edge of the image, the scale bar is suppressed. For Vertical projection, the meters per pixel is not range dependant, it is simply the VERT_SCALE.
Sets location for the center of the scale bar. This is also the point at which the range is computed. The values are in the order (line, sample). If either line or sample is negative, it is treated as an offset up from the bottom, or in from the right edge of the mosaic.
Sets overall desired size of scale bar, in pixels. This is actually the minimum size for the bar; it will likely be somewhat bigger than this in order to achieve a round dimension. See the help for BAR.
DN for the bar and bar labels. See BAR keyword. Note, a BAR_DN of 0 is transparent (i.e. ignored). If the number of DN's supplied is less than the number of bands, the last value is repeated as necessary.
Sets the zoom factor for the scale bar label text. Normally the text (as with all overlay text in marsmap) is 7 pixels high. Although fractional zooms are allowed, they may create undesirable aliasing in the output.
Sets the height in pixels of the scale bar end caps. The scale bar is a line going through BAR_POS, with end caps sticking up to emphasize the ends.
Sets the spacing in pixels between the scale bar and label.
Overrides the range to the terrain used for computing the size of the scale bar. Getting the range right is critical for scale bar accuracy; see the BAR parameter for more details.
By default a tilde (~) is plotted before the unit text, to indicate the scale bar is an approximation. This can be suppressed by saying -EXACT.