using pingmapper on overlapping survey tracks

[odsemblante]

Hi,

I used PINGMapper to process my sonar data on a shallow coast using Helix 10. Below is a mosaic of all three georeferenced images (with water column removed) after running main_batchDirectory.py:

The image above is a collection of all three loaded into QGIS. My survey tracks were designed to overlap so as to capture areas that were possibly left out in one pass. At first glance, the output images appear to be fine as they were somehow representative of the actual survey tracks.

However, I'm not quite sure of the results if they are correct when zoomed in due to the following: 1) there seems to be a line with higher pixel value (backscatter intensity?) at the center of each track compared to the rest; does this mean that the final output images need correction because the reflected signals from the peripheral side of the transducer have more transmission loss compared to reflections from directly under it? 2) when the survey tracks are overlapping, we should expect that the same underwater feature would appear exactly at the same position in areas where there is overlap in sonar data; but this doesn't appear to be the case as some rocks/boulders only appear in one of those overlaps, not on both. 3) there are some discontinuities in the acquired sonar data at points where the boat takes a turn to reverse the direction of travel and some tracks appear to be misaligned as well. does this have something to do with the corrections in boat speed and slant range?

I hope you can spare some time for these. Thank you in advance.

[CameronBodine]

Hi @odsemblante! Thanks for using PINGMapper!

Please consult this response for recommendations on collecting high quality sonar data.

there seems to be a line with higher pixel value (backscatter intensity?) at the center of each track compared to the rest; does this mean that the final output images need correction because the reflected signals from the peripheral side of the transducer have more transmission loss compared to reflections from directly under it?

This is called attenuation. I recommend consulting introductory information on side scan sonar. I am developing a correction for this, which will be available in v2.0, to be released in the near future. Please consult this for more information.

when the survey tracks are overlapping, we should expect that the same underwater feature would appear exactly at the same position in areas where there is overlap in sonar data; but this doesn't appear to be the case as some rocks/boulders only appear in one of those overlaps, not on both.

This is a valid expectation if you are collecting survey-grade data and using a sub-meter accuracy gps. The GPS on the Humminbird will give you similar positional accuracy to that of a Garmin hand held device or your phone. There are options to connect high accuracy GPS systems to a Humminbird via NMEA 2000 protocol, but I don't have additional information.

there are some discontinuities in the acquired sonar data at points where the boat takes a turn to reverse the direction of travel and some tracks appear to be misaligned as well. does this have something to do with the corrections in boat speed and slant range?

Please see the first link above on collecting high quality sonar data. Specifically, it has to do with making very tight turns, thus affecting the rectification process. Break your sonar recordings into separate files and you won't experience this issue.

Thanks for your interest and I hope this information helps you.

[CameronBodine]

For aligning overlapping transects, you might consider a georeferencing as a post-processing step in a GIS software.

[odsemblante]

Hi Cameron,

Thank you very much for the quick response. I will definitely consider your suggestions.

As to georeferencing the overlapping transects, I don't think it is much of an issue for me. I suppose PINGMapper was able to handle it as the resulting images are generally aligned with other layers (existing vector data).

Regards, Oliver

On Mon, Aug 28, 2023 at 12:03 AM Cameron Bodine @.***> wrote:

Hi @odsemblante https://github.com/odsemblante! Thanks for using PINGMapper!

Please consult this response https://github.com/CameronBodine/PINGMapper/issues/77#issuecomment-1651547639 for recommendations on collecting high quality sonar data.

there seems to be a line with higher pixel value (backscatter intensity?) at the center of each track compared to the rest; does this mean that the final output images need correction because the reflected signals from the peripheral side of the transducer have more transmission loss compared to reflections from directly under it?

This is called attenuation. I recommend consulting introductory information on side scan sonar. I am developing a correction for this, which will be available in v2.0, to be released in the near future. Please consult this https://github.com/CameronBodine/PINGMapper/issues/67#issuecomment-1598986034 for more information.

when the survey tracks are overlapping, we should expect that the same underwater feature would appear exactly at the same position in areas where there is overlap in sonar data; but this doesn't appear to be the case as some rocks/boulders only appear in one of those overlaps, not on both.

This is a valid expectation if you are collecting survey-grade data and using a sub-meter accuracy gps. The GPS on the Humminbird will give you similar positional accuracy to that of a Garmin hand held device or your phone. There are options to connect high accuracy GPS systems to a Humminbird via NMEA 2000 protocol, but I don't have additional information.

there are some discontinuities in the acquired sonar data at points where the boat takes a turn to reverse the direction of travel and some tracks appear to be misaligned as well. does this have something to do with the corrections in boat speed and slant range?

Please see the first link above on collecting high quality sonar data.

Thanks for your interest and I hope this information helps you.

— Reply to this email directly, view it on GitHub https://github.com/CameronBodine/PINGMapper/issues/88#issuecomment-1694703043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFLGAZBMRUS2OCMLP5WX7QTXXNVTVANCNFSM6AAAAAA4AMLXIU . You are receiving this because you were mentioned.Message ID: @.***>

-- Oliver D. Semblante +63 9228824646

---

This e-mail message (including attachments, if any) is intended for the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any utilization, dissemination, distribution, or copying of this communication or the contents therein is strictly prohibited. If you received this communication in error or by any instance unintentional, please notify the sender and delete this E-mail message immediately.

[CameronBodine]

If anything is unclear or didn't fully answer your question, please don't hesitate to reach out.

Thanks! Cam

[CameronBodine]

I did think of one option for you. If the control head is not located directly over the transducer, you can supply an x_offset and y_offset as shown here. This may help to close the spatial disagreement between overlapping transects.

[odsemblante]

Hi Cam,

Thank you for your follow up suggestion. Our setup does not have the control head directly over the transducer. But they were very close, less than a meter apart as far as horizontal separation is concerned. I was using an outrigger boat, about the length of a one-person kayak but with a narrower body.

By the way, is it possible to process the downscans only, i.e. excluding B002.SON and B003.SON? I was hoping to limit the extent of the scans to see if I could avoid some of the overlaps.

I tried to run the program without the above-mentioned files, but I'm getting these results: [image: image.png]

if using Humminbird depth: [image: image.png]

I am pursuing your suggestion to use a more accurate GPS receiver. But I suppose I would need something like a GNSS or an INS for that, which is unavailable to me this time.

So I thought maybe I could simply remove the side scan recordings. But somehow I'm stuck with those errors.

Thanks again for your help.

Cheers!

On Wed, Aug 30, 2023 at 6:29 AM Cameron Bodine @.***> wrote:

I did think of one option for you. If the control head is not located directly over the transducer, you can supply an x_offset and y_offset as shown here https://cameronbodine.github.io/PINGMapper/docs/gettingstarted/Running.html#step-5. This may help to close the spatial disagreement between overlapping transects.

— Reply to this email directly, view it on GitHub https://github.com/CameronBodine/PINGMapper/issues/88#issuecomment-1698227548, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFLGAZBIFI244JVJXVUGGR3XXZUMVANCNFSM6AAAAAA4AMLXIU . You are receiving this because you were mentioned.Message ID: @.***>

-- Oliver D. Semblante +63 9228824646

---

This e-mail message (including attachments, if any) is intended for the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any utilization, dissemination, distribution, or copying of this communication or the contents therein is strictly prohibited. If you received this communication in error or by any instance unintentional, please notify the sender and delete this E-mail message immediately.

[CameronBodine]

Can you try uploading the photos again? You may need to do it from GitHub instead of from your email. Also if you can share the main script you are running so I can see your parameter settings.

I'm not exactly sure what you are trying to accomplish with the downscan images. If you are trying to somehow make a mosaic with the dowscan, this is not possible, nor recommended. PING-Mapper will export those to sonograms, but that is all.

With that type of boat, I would recommend some sort of rudder to help maintain course over ground, if you don't have one already. Any type of heave, pitch, or roll will also impact the spatial positioning of the imagery, particularly as the range increases.

[CameronBodine]

If you are trying to limit overlap between transects, you can use the cropRange setting.

[odsemblante]

Can you try uploading the photos again? You may need to do it from GitHub instead of from your email. Also if you can share the main script you are running so I can see your parameter settings.

Here is a copy of the images I attached in the previous message:

And for the main script (attached as txt file for compatibility in pasting here): main_batchDirectory.txt

I cannot seem to find in this script the X and Y offset values of control head and transducer you were referring to last time. But I didn't bother looking because I thought they will not matter much as I'm having the conrtrol head and transducer very close to each other.

I'm not exactly sure what you are trying to accomplish with the downscan images. If you are trying to somehow make a mosaic with the dowscan, this is not possible, nor recommended. PING-Mapper will export those to sonograms, but that is all.

Indeed, that was my intention. I want the downscans sonar data only to appear in the final rectified images. With sidescans, the water column should be removed to achieve a continuous image of the underwater features. But the patched images from the left and right hand sides of the transducer will have discontinuities at the joining edges. See here:

I was thinking that if I use the downscans only, I may not have these problems. Although I will be loosing coverage since it will be narrower compared to sidescan results. But I am willing to have that tradeoff.

In addition, there is also a chance to "see" the same underwater features at different frequencies (low, high, mega). If I could get separate images of downscans at those frequencies, I guess I could make something out of it (ex. identification).

With that type of boat, I would recommend some sort of rudder to help maintain course over ground, if you don't have one already. Any type of heave, pitch, or roll will also impact the spatial positioning of the imagery, particularly as the range increases.

The boat I used was actually motorized (7hp).
But I don't have an INS or IMU with it to improve position. Something I'm hoping to have in the near future.

[odsemblante]

If you are trying to limit overlap between transects, you can use the cropRange setting.

Is this found in main_batchDirectory.py?

[CameronBodine]

Thanks for following up.

The side scan channels are required to use the automated depth method, which I adapted from Zheng et al. 2021. PINGMapper is also expecting the side scan channels to be present when using the Humminbird depth. My research is focused on developing workflows to process the side scan data, therefore you can expect errors from the program if those files are not present.

The batch script you posted appears to be from an old version of PINGMapper. Please update your installation by following these instructions and use the new main_batchDirectory.py script in the PINGMapper folder. This is a "living" software that I am actively developing so you should plan on regularly updating the software. The cropRange and x and y offset parameters will be available.

Indeed, that was my intention. I want the downscans sonar data only to appear in the final rectified images. Thanks for clarifying. Unfortunately this is not a feature available in PINGMapper.

With sidescans, the water column should be removed to achieve a continuous image of the underwater features. But the patched images from the left and right hand sides of the transducer will have discontinuities at the joining edges.

This is due to an imperfect detection of the depth, either from the sonar sensor or the automated procedures provided in PINGMapper. If you read the Zheng paper I linked above, you will find this is an issue with survey-grade systems as well. You can force the removal of the anomalies you are seeing by specifying a positive value for adjDep.

I was thinking that if I use the downscans only, I may not have these problems. Although I will be loosing coverage since it will be narrower compared to sidescan results. But I am willing to have that tradeoff.

You will likely experience similar issues with the downscans as the water column would need to be removed, which is again reliant on accurate depth picks. Also, data from the down-looking sonars are intended to be interpreted in the Z-direction and there isn't a method I'm aware of that would accurately project these data on an XY plane. You can investigate alternatives to PINGMapper, such as SonarTRX or Reefmaster, to see if they support the functionality you are after.

It sounds like you have a good setup for collecting data. Note that PINGMapper doesn't have a method to correct spatial position from auxiliary files. This may change in the future. You can follow #84 to see when and if that changes.

[odsemblante]

Cam, I think I found a way to address my troubles with overlapping transects without having the need to record each transect separately. Mosaicking the final output into one raster image actually enforces the overlap. Obviously, that is expected considering how I acquired the data.

However, the records are still there just layered on top of the other. I initially thought they will be interlaced during mosaicking in PINGMapper.

And it is possible to access those underlying layers by mosaicking per chunk of processed sonar recording only. Not all of them into a single georectified sonar image.

In that way I can export them later on GIS and select which chunk belongs to the transect I am interested with. Then do the mosaicking manually or by batch script there.

It is a bit tedious since there will be several raster images, not to mention the disk space consumed. But it works for me because I can rectify distorted parts of the sonar image such as when the boat makes a turn during acquisition.

I'm working out to incorporate a Trimble GNSS receiver into my rig right now as you suggested. Hopefully this will significantly improve the position of my georectified images.

Thanks again for your help.

Cheers!

[CameronBodine]

I'm glad you were able to work around the issue! Thanks for the update. I'll close this issue. Feel free to open any other issues as they arise. Cam