Bottom Detect Editing (A Primer)

Bottom detect editing is the process of determining the first acoustic return for each ping. MR1 bottom detects are generated and graphically viewed and edited using the program btyp, which operates on hour-long MR1 raw data files. Once the bottom detects have been generated for an hour's worth of pings, it is up to YOU, the data processor, to evaluate the results and manually edit the bottom detects in order to produce high quality sidescan and bathymetry data.

This primer will guide you!

1. Generating the bottom detect time series

Start up btyp on a raw hourfile, using a parameter file if required:

btyp MR19724015.00 -a mw9719.01.parms &

Take a look at the bottom-detect attributes by using the right-hand

mouse button to select

Bottom Detect --> Attributes

Set up your parameters to initially generate the bottom detects:

click on the "Continue" button to accept the values you selected

Generate the bottom detects (right-hand mouse button again):

Bottom Detect --> Generate

bdfig_01.gif (click on image for an expanded view)

The bottom detect time series will appear in the upper half of the window; port bd's are red and starboard are green. Check out the continuity of the curves -- if they're continuous and without high or low outliers, then you're done. In this example (Figure bdfig_01.gif), however, there are many shallow outliers that need to be eliminated.

At this early stage, it's easiest to change your bd attributes and regenerate the curves. Try this:

Bottom Detect --> Attributes

Continue

Bottom Detect --> Generate

bdfig_02.gif (click on image for an expanded view)

Oops -- the relative threshold we selected was too high, resulting in bottom detects that are too deep (Figure bdfig_02.gif). These two examples illustrate how the relative threshold determines the bottom detect. For thresholds that are too low, ambient water column noise will exceed the threshold, resulting in a too-early (shallow) bottom detect for a given ping. Too-high thresholds miss the first break of the real bottom, and are triggered by high magnitude samples later in the ping, resulting in a bottom detect that is too deep.

In our example, we can generate a reasonable bottom detect curve by selecting appropriate values for minimum depth and magnitude threshold:

Bottom Detect --> Attributes

Continue

Bottom Detect --> Generate

bdfig_03.gif (click on image for an expanded view)

This worked (Figure bdfig_03.gif) because the Minimum Depth value of 3000 prevented water column noise from causing a false (early) trigger, and the Relative Threshold value of 0.04 was small enough to capture the earliest increase in echo amplitude that represents the first acoustic return.

2. Bottom Detects and Bathymetry

The purpose of bottom detects for bathymetry is they eliminate all the water column data from being processed, making the btyp calculation a bit faster and the resulting data files a bit smaller. Individual bathymetry soundings are given x and z values based on their two-way travel time and their phase angle. For these reasons, the most important criterion for bottom detect editing as it pertains to bathymetry is to make sure the bd is not too deep.

GENERAL RULE: don't use bottom detects that are too late (deep), because they will result in the loss of bathy data near nadir. Early (shallow) bottom detects are not so bad, so err in the shallow direction (if you must err).

bdfif_04.gif (click on image for an expanded view)

Figure bdfig_04.gif shows what happens when you use bottom detects that are too deep. In this case the port (red line) bottom detect was used to generate the bathymetry -- see how there's no bathy near nadir in the right half of the file? The too-deep bottom detects caused good data from the early part of the echo to be ignored during the bathymetry calculation, resulting in the data gap at nadir.

bd_fig05.gif (click on image for an expanded view)

The same file is processed using reasonable bottom detects in Figure bdfig_05.gif, showing the resulting good bathymetry. Once again the port bottom detects were used, but this time they include the two hills that were cut off in the previous example. A good way to evaluate the quality of bottom detects (as they relate to bathymetry) is whether data are continuous across nadir.

3. Bottom Detects and Sidescan

When we generate and display MR1 sidescan data, the locations of each pixel within a ping are positioned based on a flat-bottom assumption. This means that for each ping, pixels are displayed away from nadir assuming that the seafloor is planar and horizontal at the depth measured by the bottom detect. While this generally results in pretty good sidescan, there are instances when topography should really be accounted for in order to correctly place the pixels. Because we can't currently do this, and because we are limited to using the same bottom detect value for both port and starboard sides, these instances result in mislocated sidescan pixels.

The bottom detect time series, while representative of the near nadir depth variations along track, are often not representative of the broad across track depths that are more appropriate for laying down sidescan.

When the flat-bottom assumption breaks down, we can usually minimize the distortion on one of the two sides, but not both. To maximize the aesthetic appeal of the resulting sidescan mosaic, we usually opt to minimize the distortion on the deeper side of the swath. This results in sacrificing near-nadir sidescan data from the shallow side of the swath, but yields a sidescan image that has fewer gaps along nadir.

So what's this mean for generating bd's for sidescan? Try starting out with the best bd time series that you can automatically generate. Look at the sidescan, and if the sidescan is continuous across nadir (and geologic structures appear reasonably imaged), you're done. However, if you see any scallop-shaped gaps along nadir (water column data displayed due to too-early bottom detects), you've got more work to do. Over these areas, you'll need to use a bottom detect that will properly display the deeper side of the swath. This often involves iterative hand-editing to create a customized bottom detect time series.

GENERAL RULE: Don't use bottom detects that are too early. Over rugged areas, use a bottom detect that's deep enough to get rid of water-column data on the deep side of the swath.

bdfig_06.gif (click on image for an expanded view)

Figure bdfig_06.gif shows an example where the bottom detect is probably pretty accurate for the shallow port (top) side. However, on the right side of the image there's a whitish low-backscatter region along the starboard side of nadir indicative of a too-early (shallow) bottom detect for the deeper starboard side.

bdfig_07.gif (click on image for an expanded view)

The same file is shown in Figure bdfig_07.gif, this time processed using a deeper bottom detect. The result is that the inner-swath data are now located closer to nadir, and the white gap that was evident along nadir has disappeared. Changing the bottom detect depth has the greatest effect on near-nadir data; at farther ranges the data are progressively less effected (due to time and geometry -- figure it out yourself).

NOTE: The maligned "Mean Bathymetry Slope" option *does* do a good job to minimize the distortion in both sides of the swath in rugged areas, using a common bottom detect. The problem, though, is that there is enough ping-to-ping variability in the mean across-track slope that the sidescan appears jittery. This could be eliminated by filtering the slope along track (eg a 5-ping running average) so that the change in slope between pings is smooth and minimal. The fact that this option works as well as it does bodes well for our plans to impliment a layover correction.