FMGT - Processing Pipeline
FMGT uses an optimized, multi-core, stage-based processing pipeline to accomplish its job. Understanding how this pipeline proceeds can help you more efficiently use FMGT. The generic pipeline architecture is shown below.
Generic Processing Pipeline
FMGT uses our internal high-performance I/O library to maximize reading of survey data from disk to achieve near theoretical maximum throughput. Results of a processing stage are persisted in the user project to further eliminate the need for re-processing when something in the project changes. FMGT then further increases overall performance by parallelizing this stage processing architecture as shown in the Parallel Stage Processing figure.
Parallel Stage Processing
FMGT stage processing not only reduces the need for re-processing under various circumstances but also enhances protection against unexpected faults or system failures. Since each stage mimics the same architecture, any failure will result in the system picking up where it left off instead of starting back from the beginning when restarted.
FMGT Processing Stages
FMGT has five primary processing stages as shown in the figure above. Each one of the first three processing stages depends on the output of the previous stage. The final three stages depend on the first three, but not on each other.
The Coverage Processing stage extracts the navigation from each line and creates the visual port, starboard and nadir track lines that will be shown in the FMGT Map View.
The Backscatter, or 'Adjust' (as it is now known) Processing stage extracts the raw backscatter time series for each beam from the source file and performs all potential adjustments to the data. These adjustments include proper signal level adjustment due to range and transmission loss, beam incidence angle and beam footprint area adjustments, Lambertian scattering adjustments and other adjustments particular to the specific sonar.
The Filter Processing stage will perform adjustments to the backscatter swath based on beam angle and finally perform an antialiasing pass on the resulting swath backscatter data.
The Angle Range Analysis (ARA) stage attempts to compute a characterization of the underlying backscatter surface.
The Statistics Processing stage computes a multi-layered statistical surface with attributes such as the Mean or Median value of a statistical cell based on all of the beam data that intersects the cell. Hence, the statistics layers have a coarser resolution because of the information needed to compute for each statistic resulting cell (neighbours).
The three product stages are shown in the Generic Processing Pipeline figure below. These products depend on the first three processing stages to be completed and additionally ARA or Statistics processing to be completed if those layers are to be built.
This "stage-dependency" is an important concept to understand when using FMGT. FMGT always knows what processing has been done to each line in the project. When particular processing or products are requested, FMGT will know what needs to be accomplished first before it proceeds.
For example, when you load lines, coverage processing is automatically performed to extract the extents of the swath at each ping as well as navigation information that will be used later. If you then click on the Mosaic button on the processing panel, FMGT will perform backscatter processing, filter processing and finally mosaic rendering. It knows that it needed to accomplish the other stages to provide the final product you requested. If you then wish to change the mosaic resolution, FMGT will proceed directly to mosaic rendering as reprocessing of the data is not necessary when changing resolution.
Generic Processing Pipeline
Certain changes to processing parameters as explained in section 1.7.3 will result in stages requiring reprocessing. Typically, changes to processing parameters will cause FMGT to invalidate the dependent stage flags for the project lines. So if the user requests a new product, FMGT will know what needs to be reprocessed. The user can also force reprocessing of a particular stage by clearing the processing flag of that stage explicitly. All of this is explained in detail in section 1.10.2.