Level 2 Help for MARSORTHO

INP

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.

The input images can be 1-band or multi-band. The input images must be 
co-registered to the images provided in IN_XYZ parameter.


IN_XYZ

There are two options for describing IN_XYZ.

Either:
List the image file names

Or:
provide an ascii file with the file names listed, one per record.

The input images must be 3-band in REAL (float) format. The bands are in x, y, z
order. The input images must be co-registered to the images provided in INP 
parameter.


OUT

Output image contains the ORTHO mosaic.


OUT_DEM

Output image contains the DEM mosaic.


NAVTABLE

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.


IMG_NODATA

Defines what value to be used for the no data areas in ORTHO output. The 
default value is 0.0. The value is going to be used as a flag to distinguish
whether a position has a valid data or not, so the value of IMG_NODATA is better
be set outside the image range.


DEM_NODATA

Defines what value to be used for the no data areas in DEM output. The
default value is the maximum floating point number, which is 3.40282E+38.
The value is going to be used as a flag to distinguish whether a position 
has a valid value or not, so the value of DEM_NODATA is better be set 
outside the image range.


FILL_SIZE

Defines the size in pixel for fill implementation. 


FILL_METHOD

Defines the method for fill implementation. UNIFORM mode will fill all the
boxes with a uniformed size defined by FILL_SIZE. WEIGHTED mode will use
the distance between a pixel to camera as the weight. The pixel that is 
closest to camera will be assigned fill size 1, and the pixel that is 
furthest away from the camera will be assigned fill size defined by 
FILL_SIZE. The fill sizes of pixels in between will be linearly mapped. 


DEM_FILL

Override FILL_SIZE for DEM output.


RANGE

Specifying a range will override the automatically determined min/max x/y,
so for example saying range=50 will set the output to +/- 50 meters in
both directions. This can be overridden by the specific MIN/MAX X/Y parameters.

If RANGE is given and CUT is not, the default for CUT is to cut a circle
at the same size of RANGE.


CUT

Specifies the size of the circle/sawtooth shape (see CUT_TYPE) at which to 
cut the data, as a 2D distance from the coordinate system origin or a 3D 
distance from camera. If the value is 0, no cut is performed (i.e. the output 
goes to the corners of the rectangle). If the value is undefined, the value of 
RANGE is used.

Thus specifying RANGE=50 will set the size of the image to +/-50 meters
and do a circular cut at 50m distance.  RANGE=50 CUT=40 will set the image
to 50 meters in size but cut all data at 40m (thus leaving missing data
around the circle).  RANGE=50 CUT=0 will set the image to 50 meter range
but not cut in a circle.  CUT=50 will not set the size of the image (it
comes instead from the auto min/max x/y, parameters, or NL), but it will
cut a circle at 50m.


CUT_TYPE

CIRCLE = 2d distance from coordinate system origin, results in circular image.  
SAWTOOTH = 3d distance from camera (each camera), results in sawtooth pattern 
for typical mast-mounted camera panoramas since the camera origin changes with
each image.


BAND

The BSQ input file band number. Defaults to undefined. The parameter defines
which band(s) in skin images will be processed to put in ORTHO output mosaic.
If BAND=N, then only that band in skin images will be processed. If BAND is 
left to be undefined, then all bands in skin images will be processed.


MINX

Specifies the minimum extent of the image in meters in the X direction. If MINX 
is undefined, the program computes the minimum x value from the XYZ data 
provided with IN_XYZ parameter. If parameter RANGE is provided, then MINX is 
overriden by -RANGE.


MAXX

Specifies the maximum extent of the image in meters in the X direction. If MAXX
is undefined, the program computes the maximum x value from the XYZ data
provided with IN_XYZ parameter. If parameter RANGE is provided, then MAXX is
overriden by RANGE. 


MINY

Specifies the minimum extent of the image in meters in Y direction. If MINY
is undefined, the program computes the minimum y value from the XYZ data
provided with IN_XYZ parameter. If parameter RANGE is provided, then MINY is
overriden by -RANGE. 


MAXY

Specifies the maximum extent of the image in meters in Y direction. If MAXY
is undefined, the program computes the maximum y value from the XYZ data
provided with IN_XYZ parameter. If parameter RANGE is provided, then MAXY is
overriden by RANGE.


SCALE

The scale for both DEM and ORTHO output mosaic, it is measured in meters per 
pixel. If it is defined, the mosaic will be set exactly at that resolution.
If it is undefined, then SCALE will be computed based on NL, MINX, MAXX. Either
SCALE or NL needs to be provided for the program to compute output's geometry.


OVERLAY

Keyword parameter that provides 6 different methods of handling overlay areas
in DEM and ortho output mosaic. It defaults to method FIRST.
1. CLOSEST = closest to camera.
   When multiple points hit the same position, the one that is the closest to
   the camera will be picked and written in the output mosaic. This method 
   should give the best result if input XYZ data contains lesser noise.

2. AVG = average.
   When multiple points hit the same position, the average value of the points 
   will be picked and written in the output mosaic.
    
3. MIN = minimum.
   When multiple points hit the same position, the minimum value of the points 
   will be picked and written in output mosaic. 

4. MAX = maximum.
   When multiple points hit the same position, the maximum value of the points 
   will be picked and written in output mosaic.

5. FIRST = first on top.
   If this mode is enabled, depending on the images order in the input list,
   the points from images on top of the input list will have higher priorities 
   to be picked and written in the output mosaic. For example, given the 
   input list to be in the order of img1, img2, and img3, points come from img1 
   will be picked when there are overlap areas between img1 and img2; points 
   come from img2 will be picked when there are overlap areas between img2 and 
   img3.   

6. LAST = bottom on top.
   If this mode is enabled, depending on the images order in the input list,
   the points from images on bottom of the input list will have higher 
   priorities to be picked and written in the output mosaic. For example, given 
   the input list to be in the order of img1, img2, and img3, points come from 
   img2 will be picked when there are overlap areas between img1 and img2; 
   points come from img3 will be picked when there are overlap areas between 
   img2 and img3.


RAD

Keyword parameter that turns on or off radiometric correction of the input 
images. RAD (the default) enables the correction (for missions/instruments which
support it), while NORAD disables it. For input images which are in REAL(float) 
format, radiometric correction is disabled. 


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.


INPUT_RANGE

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.

The input numbers are 1-based.  If only one number is specified, it is the
starting number; the end defaults to the # of inputs.


MORPHOLOGIC

Flag to enable erosion feature. If it is on, then the program will erode the
borders of generated DEM and ORTHO results. Note that the erosion will feature
will erode all the holes in DEM and ORTHO results.


ERODE_SHAPE

Structuring element shape for erosion feature. Currently, two default shapes
SQUARE and DIAMOND are provided. Using different structuring element shape
will cause the program to erode borders and holes differently.


ERODE_FACTOR

Defines how much to erode borders and holes. If it is on QUARTER mode, then 1/4 
of the fill will be removed. If it is on HALF mode, then 1/2 of the fill will
be removed. If it is on FULL mode, then the entire fill will be removed.


NL

Number of Lines for both DEM and ORTHO output mosaic. If it is defined, the
number of lines of the mosaic will be set exactly to that number. If it is 
undefined, it is computed based on SCALE, MINX, and MAXX. Either NL or SCALE
needs to provided for the program to compute output's geometry.  


CONFIG_PATH

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 projects 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).


POINT_METHOD

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:


NOSITE

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.


DATA_SET_NAME

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.


DATA_SET_ID

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.


RELEASE_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.


PRODUCT_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.


PRODUCER_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.


PRODUCER_INST

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.


TARGET_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.


TARGET_TYPE

Specifies the type of a named target. This value is copied to the output
label, property IDENTIFICATION, keyword TARGET_NAME.


RSF

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.


DEBUG_RSF

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).


COORD

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.  This is the ultimate reference frame
    (see also FIXED_SITE for rover missions).
Instrument - (default) 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).  For MSL, this is the
    Rover Nav frame.
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.
RMECH - for MSL, this is the Rover Mechanical frame.  It should not normally
    be used except for testing.


COORD_INDEX

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.


FIXED_SITE

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.


SOLUTION_ID

Specifies which solution ID to use when specifying the coordinate system.

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.  Without
it, the "best" available solution is chosen.

It is extremely rare that this parameter should be needed.  The default
will be sufficient in almost every case.

Note that the current MER implementation requires that a value for COORD_INDEX
also be provided, in order for this parameter to take effect.