Level 2 Help for MARSAUTOTIE2

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.


OUT

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


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.


BAND

The vicar image band number. Defaults to 1


PAIR_MATCH

This defines the image pairing strategy for tiepoints search.
The default value (0) means that all images are going to be matched with all
other images in the list. This is a pairwise combination among all the inputs.
Two other pairing strategies are available depending on the value and sign of
PAIR_MATCH.
If PAIR_MATCH is strictly positive, then the value of PAIR_MATCH indicates, for any 
image in the input list, the number of neighbooring images (before and after) 
that it will be compared to. Neighbooring refers to position in the list. 
For instance:
If PAIR_MATCH=1: im1 will be compared to im2, im2 will be compared to (im1,
im3), im3 will be compared to (im2, im4), etc.
If PAIR_MATCH=2: im1 will be compared to (im2, im3), im2 will be compared to 
(im1, im3, im4), im3 will be compared to (im1,im2,im4,im5), im4 will be
compared to (im2,im3,im5,im6), etc. Think of it at a sliding window with 
overlap.
If PAIR_MATCH is strictly negative, the strategy will be to compare disconnected
subgroup of images of size abs(PAIR_MATCH). For instance:
If PAIR_MATCH=-1: im1 will be compared to im2, im3 will be compared to img4, img5
will be compared to img6, etc.
If PAIR_MATCH=-2: im1,im2,im3  will be compared to each other; im4,im5,im6 will be
compared to each other; im7,im8,im9 will be compared to each other; etc. Think
of it at a sliding window without overlap.


REFIMAGE


REFIMAGE, IGNORE, IGNORE_INTRA allows further strategies for the pairing of 
images to be tiepointed set by PAIR_MATCH. It is expected that if REFIMAGE,
IGNORE, IGNORE_INTRA are used then PAIR_MATCH is most likely to be set to 0, 
but that is not a requirement.

REFIMAGE specifies which image (if any) are reference images.

References images are not tiepointed between each other, meaning that any pairs
defined by PAIR_MATCH strategy that is made of two references will be deleted
from the list of pair to be tiepointed.
Any pairs defined by PAIR_MATCH that contains a reference and a non-reference 
images are kept for tiepointing.

REFIMAGE=-1 means no reference image.

REFIMAGE can be a single image, or a list of images.  Each image in the list 
will be a reference image.  This allows any arbitrary images to be selected
as references.  If an image number 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,3,4,5,6,8,11,12,13,14,15

Numbering of images starts at 1.



IGNORE

Any image in the IGNORE list won't be considered for tiepointing. So, any pair
of images defined by PAIR_MATCH that contains an images listed by IGNORE will
be deleted from the list. Essentially it allows to "remove" an image from the
list of input without modifying the INP file while keeping the image indexes
in the output file.
IGNORE can be a single image, or a list of images. See REFIMAGE for numbering
scheme.


IGNORE_INTRA

This keyword will delete from the pair list any pairs that are made of two
non-reference images (REFIMAGE). If REFIMAGE is not used, IGNORE_INTRA has
no effect.




NUMTILTS

The number of tilts to simulate affine transformation between the two images.
For each tilt, a number of rotations is defined such that the range of 
possible affine transformation is reasonably well sampled. For instance, a
tilt number of 5 will lead to 26 tilts/rotations pair. That is, 26 affine
transforms will be simulated on both left and right images. Then, keypoints
detection and matching on all possible pairwise combinations (i.e., 676) between
these 26 transforms will be carried out. This can grow fast! See NBESTMATCHES
for optimization.
Note that in any case, matchings between the native (non-affine transformed)
images is carried out. If NUMTILTS <=1, then no affine simulation is carried out
and matching is done on native image only (i.e., SIFT instead of ASIFT).   


EPIMAXEDIST

Each keypoint in the left image will be match to a subset of keypoints in the
right image that satisfy a proximity constraint to the epipolar line 
corresponding to the left keypoint. EPIMAXEDIST defines the maximum distance
(in pixel) between a right keypoint and the epipolar line for that keypoint to 
be part of the subset of keypoints to be matched to the left keypoint.
If EPIMAXDIST < 0, no gemometric constraints is applied. Default is -1.


POSMAXDIST

Each keypoint in the left image will be match to a subset of keypoints in the
right image that satisfy a proximity constraint to the left keypoint location. 
POSMAXDIST defines the maximum distance (in pixel) between a right keypoint and
the position of that keypoint to be part of the subset of keypoints to be 
matched to the left keypoint.
This keyword is mostly usefull for images of the same size and for which a 
feature in one image is expected to be roughly at the same location in the
other image. It allows to reduce the chance for a feature to be matched to
a similar-looking but unrelated one elsewhere in the image.
If POSMAXDIST < 0, no gemometric constraints is applied. If POSMAXDIST and
EPIMAXDIST are on, EPIMAXDIST has precedence. They cannot be combined. Setting
POSMAXDIST while EPIMAXDIST is defined (>0) has no effect. Default is -1.



NBESTMATCHES

The number of affine simulations and matchings can grow fast with the number of
tilts which can take a long time to process. If NBESTMATCHES is not null, a 
first run on lowered resolution images will be carried out and the 
NBESTMATCHES affine combinations leading to the most matches on low res images
will be carried out on full resolution images. The observation is that on all
the affine transform testes, only a handful will provides good matches. Affine
transformation that are too far from the real ground situation do not provide
matches. If NBESTMATCHES <= 0, then no low res process is done and all the affines
simulations are carried out at full resolution. Default is 0.


CROSSCHECK

If ON, once the matching is done between the left and right images, a new 
matching is processed inverting the left and right images. Matches that are not 
corresponding in both list (L/R R/L) are discarded from the ouput matches
list. This a way to filter out some of the bad/weak matches.


OCTAVE

Defines the number of downscaling to apply to the images (by a factor of 2
each time). An internal limit sets the minimal size of the downscaled
image to approximately 12x12 pixel, whatever larger is the octave number
input. The downscaling allows to simulate lower resolution image of the
scene. Default is to go down to the limit (12x12).


SCALES

Number of blur passes to apply to each octave. The blurring is done through
gaussian filtering simulating different zoom situation. Default is set to 3
which is quite common in SIFT usage of SIFT.


MATCHRATIO

Ratio below which a match is not deemed reliable enough and discarded.
During matching, a left keypoint is compared to a list of right keypoints. For
each comparisons, the euclidean distance between the left keypoint description 
and the right keypoint description is computed. The smaller the distance, the 
better as that means that the left and right keypoints "look" similar. However,
setting an absolute threshold on the distance to accept/reject a match is not 
trivial to adjust. Instead, the ratio between the best and second-to-best 
distance (i.e., the smallest and second-to-smallest distances) is computed. A 
large ratio indicates that the best keypoint is significantly better than all 
the other keypoints, which suggests that the match is correct.
If the ratio is too low, then discrimination between the best and second-to-
best cannot be done with confidence (too similar). The match is rejected and
no tiepoint is created.


UPSAMPLE

It has been shown that upsampling the input image by a factor of 2 augments
the number of keypoints detected. It comes at the cost of a longer processing
time. The total number of OCTAVE includes the upsampled image.


INITSIGMA

At each octave, the image is blurred SCALES times with increasing blurring
intensity. This parameter sets up the blurring intensity of the first scale.
It must be set up according the the natural blur in the original input. It
has been showed experimentally that for "normal" image, and INITSIGMA between
1.2 and 1.8 is usually good. Default value is set up to 1.6. Augment INITSIGMA
if the image is noisy (low pass filter equivalent).



DOGTHRESHOLD

A pixel is classified as a keypoint if it is the location of an extrema in the
Difference Of Gaussian (DoG - This is the difference between the image at  
two different scales). However, noise can be source of false extrema. To limit
the false detection, the magnitude in the DoG has to be significant. This 
parameter sets a threshold on the DoG below which the point is not classified 
as a keypoint. The magnitude of the DoG depends on the number of scales. The 
more scales, the smaller are DoG values. DOGTHREHOLD is the value of the 
threshold corresponding to SCALES=3. It is set to 0.0133 (=0.04/3) 
corresponding to a good compromise (experimentally defined and generally 
accepted in the litterature - intial value from Lowe's paper). 
If SCALES is changed to value different than default=3, then DOGTHRESHOLD will 
be adjusted accordingly in the program. DOGTHRESHOLD can be modified by user, 
but will still be considered the threshold for SCALES=3. A larger value
imposes a more drastic contrast in the DoG, filtering out more bad keypoints, 
but also removing good ones.


EDGETHRESHOLD

This parameters eliminates points identified as extrema and which lay on edges.
An edges is not a good keypoint as its discrimination is not robust along the 
edge. To filter out these points a Harris definition of a corner is used, by 
looking at the ratio between the largest and smallest eigenvalues (largest and 
smallest curvature) of the point surrounding. Default is set to 10, which means
that if the ratio between the largest and smallest eigenvalues is larger than
10, the point is deemed sitting on an edge and discarded. Larger value will 
filter out more points (more conservative).


BORDER

The width of a border all around the image to avoid in selecting
pixels for keypoints.


MASK

This keyword activate a masking/discarding step. If on, keypoints that are 
found on, or near (see DILATEMASK) pixel with a specific value are rejected.
Typically this is useful if there are areas of the image where we don't want
keypoint to be selected. For instance, dark band, masked feature, dust spot
on the lense, etc... If these areas are masked with a specific value (usually
0) then all keypoints found on pixel with intensity=0 are discarded. This is 
to avoid false matching between features that are not related with the scene.


VALMASK

The value of the pixel that will be flagged as mask. For instance, if 
VALMASK is set to 0 (the default), then all keypoints found on pixel of value
0 will be discarded. This keyword has no effect if MASK is turned OFF.


DILATEMASK

Because of the multi-scale approach of SIFT, a masked area can bias pixels
that are nearby and not only pixel that are "on" the masked area. To also
reject keypoints that are found in the direct vicinity of the masked pixel,
the masked areas is "dilated" by DILATEMASK pixels. Default is 0, i.e., no
dilation applied. This keyword has no effect if MASK is turned OFF.


SEP_ANGLE

Maximum difference (in degrees) between the look directions of the two 
cameras. If the difference in look direction is larger, the pair is not going
to be run for tiepoint matching. This avoid useless attempt at finding tie
points between images that have look directions not converging.


MAX_TIES

The program, depending on the images, can return a huge amount of tiepoints per
pair which may render the use of subsequent programs problematic (i.e., marstie
that will take a huge time to load up all the tiepoints). This parameters limit
the number of tiepoints to be saved in the output files. The program will find 
all the tie points it can, but only MAX_TIES tiepoints randomly selected in the 
list (for each pair) will be saved to file. Default is 0, which means no limit, 
save them all.
Note that a better approach would be to save the MAX_TIES tie points in such a
way that they are spatially well spread. Or may be based on their confidence
score. Experiment shows that random selection gives *about* good spatial spread.


GTM

By default GTM is set to 0, which means no graph filtering. 
This post-process filter is applied to the set of tiepoints found. It 
implements the paper:
"A robust Graph Transformation Matching for non-rigid registration"
Image and Vision Computing 27(7):897-910. June 2009 
If GTM is set to a value > 0 then it activates the GTM filter and the
value indicates the number of points of the local graphs.
GTM relies on the hypothesis that the transformation that occurred between both
images is locally reasonably smooth, such that neighbour points in the first 
image should correspond to neighbours points in the second image. The number of 
points considered to be in the neighborood is set with GTM parameter. The filter
will check that hypothesis and iteratively remove points that do not satisfy it.
This approach is very good at filtering out gross outliers. The larger the GTM
value, the more constrained will be the graph, the more points will be removed 
due to parallax non-smoothness. Early tests show that a GTM value of 3-4 gives
a good trade off between filtering out outliers and removing too many good 
points. A GTM value of 1 doesnt do anything and is equivalent to 0.




START_KEY

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.


FORMAT

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.


OMP_ON

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.


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


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:


MATCH_METHOD

Specifies a method for pointing corrections.

Loose method matches with pointing parameters of the image.
Tight method matches with unique id of the image.


MATCH_TOL

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


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.


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

This parameter is ignored by marstie.  It is here for compatibility
with subroutines used by other programs (see e.g. marsmap).


COORD_INDEX

This parameter is ignored by marstie.  It is here for compatibility
with subroutines used by other programs (see e.g. marsmap).


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.