pointreg

The main purpose of "pointreg" is to apply a chosen pattern matching algorithm (DEFFILE) to subpixel (or, less commonly, whole pixel) register individual control point coordinates (measures) that have been collected between images and stored within an input control network.

"Pointreg" requires that for every serial number (SN) that exists in the input control network, there is an existing cube file and its associated filename is included within the input list (FROMLIST).

Most often the input control point network (CNET) contains A priori sample and line positions based on the original SPICE of the images. For creating an initial control network, refer to applications such as "autoseed", "seedgrid" and/or "qnet".

Due to many factors, often including inaccuracies with the camera pointing, the control point's initial measure coordinates between images are not registered to one another with subpixel -- or even whole pixel -- accuracy.

The input control network contains certain fields that are evaluated by "pointreg" (POINTS, MEASURES) in order to know whether or not to work on a control point and the associated measures. "Pointreg" in turn adds or updates fields in the output control network that reflect the successes and failures of the pattern matching for each measure.

For every control point within the input network, there are control measures. For each control point there is always one and only one associated reference measure, either set explicitly or chosen at runtime implicitly. Explicit references are chosen and defined as such either manually by users ("qnet") or automatically with an interest operator ("cnetref"). Implicit references are determined when no explicit reference is set for a point. In such a case, the control point will provide its first valid (Ignore=False) measure to act as the reference.

Once "pointreg" has a reference measure for a point, it attempts to every other measure in the point to that reference location. An implicit reference will then be made explicit, and if any of the registrations succeed, the reference will also be made valid.

With every successful subpixel registration for each control measure, the sample and line values within the output control network are updated with the resulting subpixel coordinates. Note that the reference measure coordinates are "fixed" while the coordinates of the remaining measures are adjusted based on the pattern matching output. The a priori sample and line fields are assigned the original starting input pixel coordinates. Applications such as "qnet", will report the sample and line shift as a result of "pointreg". "Pointreg" will also update the control network with the pattern match coefficient results such as minimum and maximum "pixel z-score" and "goodness of fit".

With every failed subpixel registration for each control measure, the non-reference measure is set to ignored (Ignore=True). If all the measures within a control point are ignored (Ignore=True), then the entire control point is set to ignored (Ignore=True) at the control point level.

Description

This file contains a list of cube filenames (one per line), each mapping to the serial number of one of the control measures that is to be used in registration. For every control measure that will be registered or used as a reference during registration, its serial number must have an associated cube in this list.

Description

This file contains the initial control network whose points are to be registered.

Description

This PVL file contains all the user-specified options for performing automatic registration on the points in the network. The default "template" definition file contains all the keywords AutoReg will accept set to their default values, or common example values where defaults do not exist. For an in-depth discussion of all the options available to the user in this definition file, please see the Pattern Matching guide referenced above.

Description

This is the output control network containing all the newly-registered points in addition to anything left unchanged from the input network.

Description

This file will contain data collected from the pointreg application. The data will be comma-separated and contain a line for each measurement of all non-ignored points in the output control net. This will include the point id, orignal sample position, original line position, new sample position, new line position, sample difference, line difference, minimum z-score, maximum z-score, and goodness of fit.

Description

By enabling this option, any point that is "ignored" in the input network will be removed in the output network. If the user specifies with the POINTS option that they only want to register NONIGNORED points, then any ignored point will be immediately removed with this option enabled. After registration is complete, if a point has less than 2 valid measures, and is not a "fixed" point, then it will be set to ignored, and with this option enabled, removed from the output.

Description

When enabled, control measures that failed to register in the current run of "pointreg" will remain in the output control network.

Description

If this parameter is set to IGNORED, ignored points will be reprocessed. It may set them to "valid" if they are acceptable in a new tolerance range. If this parameter is set to the default value of NOTIGNORED, only the "valid" or "non-ignored" points will be registered. Otherwise, if it is set to ALL, every point will be registered. Note that if certain Control Points will not be processed, it implies that all their measures will not be processed as well.

Description

If this parameter is set to CANDIDATES, only measures that have not been successfully registered by a prior run of the "pointreg" application will be processed. However, if this parameter is set to its default of ALL, every measure -- including those that have been run through "pointreg" successfully, and those that were manually selected -- will be processed. A measure is considered a "candidate" if it has never been run through "pointreg" before, or if it was unsuccessfully registed in a previous run.

Description

Validating the control network attempts to weed out false positive registrations based on a series of tests. When a measure fails a given test, its type will be set to CANDIDATE, its line and sample will be reset to their apriori values, and its log data will be removed. Depending on the tests selected, validation can more than double the runtime of the registration process. As such, it is disabled (VALIDATE=SKIP) by default. By selecting the AFTER option, validation will occur immediately after registration using the same definition file and control network. However, the user can also choose to skip registration and only validate the input network by selecting the ONLY option.

Description

Enabling this option causes the program to revert every measure it considers to be falsely registered back to its values prior to registration. This includes the line/sample, type, and log data of the measure. If this option is disabled, the user must enter a file to log the results for the FALSEPOSITIVES parameter.

Description

During the validation process, a much smaller search window can be used than the SearchChip from registration, as ideally, the measure position should move very little (if at all) if it is to be considered a valid registration. By default, the search window will be the PatternChip expanded by the number of pixels specified by the WindowSize parameter on each side (from the definition file, defaults to 5).

Description

Differences in image resolution can often lead to poor registrations. Because validation is itself a registration process, it can also lead to poor validations. When considering a registration to be validated, if the two measurements differ in image resolution by more than this tolerance (in meters per pixel), then the validation will be skipped. By default, this value is set to 5.0 meters per pixel.

Note that skipped registrations will be reported to the FALSEPOSITIVES report, but will not be reverted when the REVERT option is enabled.

Description

All validation tests involve registering different combinations of measures besides candidate-to-reference. Consequently, the measure positions are likely to shift slightly from their previous registrations. Ideally, there should be no shift if the two measures being examined are perfectly registered. The more the measures shift from their previous registrations, the more likely the registrations are false positives. This paraneter allows the user to specify a tolerance for how much a measure position can shift (in pixels) before the registration is considered invalid.

It should be noted that any shifting of measures that occurs during validation is for testing purposes only. The previous registration will never be overridden by the results of these tests.

Description

This file will contain a line for every registration that is determined to be a false positive. This line will include the measure serial number, reasons why it originally succeeded, reasons why it was considered a false positive, and the test that declared it as such.