Weird water feature detection

Hi all,

I know that water is always a hard core for feature detection. But since I’ve come across the follow situation quite often, I’d like to ask if anyone has any experience could share with me.

The thing is:
Whenever I’m processing images focus on aquatic environment (coral reef, seagrass, coastal area, mangrove), I always encounter one or two strip of what seems to be one image being stretched over the whole orthomosaic.
Here are some examples:

my usual setting is “–fast-orthophoto --crop 0”. I’ve also tried adjust to feature quality and min num of features, but not having any luck.

Just wondering if anyone have similar experience and what you’ve tried?



Really strange…

Can you post your typical Processing Parameters, and maybe a Report pdf?

1 Like

my usually parameter is

"--debug --fast-orthophoto --crop 0 --orthophoto-resolution 0.05"
0.05 is just trying to get the highest res, each dataset will be restricted to the 10% of GSD most of the time.
Usually when that doesn’t work, I’ll add the following since I thought it’s due to the difficulty of water feature:
"--orthophoto-compression JPEG --feature-quality medium --min-num-features 4000"

This reminds me that I was thinking of adding --auto-boundary, but it never work for me. Keep saying the command can’t be recognized. I can’t remember the docker version I was using, but I thought it’s the up-to-date one.

I’ll pull out the logs later when I’m back to my computer.


Must not be up to date if it doesn’t recognize --auto-boundary.

Are you able to share one of those datasets?

Here’s what I have as up-to-date as of just now:

docker images
REPOSITORY                   TAG       IMAGE ID       CREATED        SIZE
opendronemap/webodm_webapp   latest    0924de891f48   36 hours ago   1.6GB
opendronemap/nodeodm         latest    0ecc338059e5   5 days ago     1.76GB
redis                        latest    f1b6973564e9   2 weeks ago    113MB
opendronemap/webodm_db       latest    e40c0f274bba   5 months ago   695MB
1 Like

The version I’m using to process these three images are is ODM 2.4.8

Here is the report for:
first image:
575_report.pdf (6.9 MB)
second image:
284_report.pdf (3.5 MB)
third image:
215_report.pdf (2.6 MB)


Any specific reason you’re still under 2.4.8? We’ve made numerous changes and improvements since then.

No, I think that’s a set up issue. I thought I was making it retrieving the latest version every time. I’m gonna give the new update a go and see how it goes.


Ah, no worries. Some folks have specific reasoning and it’s important for us to keep track of what that may be to see if it is addressable in future updates.

1 Like

Hi Saijin, I’m back with this again. So I’ve updated my ODM version with the latest one. It definitely improved a lot, but still having some artifact (those long curves with empty space) around the edge. I guess, this might be just a result from less features for edge images? I’m also attaching the reports below if it helps

602_new_report.pdf (6.7 MB)

575_new_report.pdf (8.0 MB)
This one is particularly interesting that I didn’t realize that half of the images weren’t processed in the older version until I saw the new report.

215_new_report.pdf (2.7 MB)

284_new_report.pdf (3.0 MB)

If you’d wanna have one dataset to try, what would be the best way to share?


Google Drive or DroneDB, or anywhere else you can share images from


Awesome! Glad to see some good news on these data!

If I may ask, could you please export the Console Log, or the task_output.txt from the export for each task? It will help me with the settings you used for each one.


I can’t see task_ouptut anywhere, I do have a cloudwatch log from AWS, would that be the log you’re looking for?

I just took a quick screenshot fyi

1 Like

I guess the AWS log would be sufficient, if that’s what you have easy access to.

It took me a while to get all the consent of raw images, but here are two datasets that have some wierd thing with water and at the edge.
Here is the google drive link for log, report and images

Thx in advance

1 Like

I tried the following settings:

auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 1, dsm: true, dtm: true, matcher-neighbors: 0, mesh-size: 300000, min-num-features: 64000, orthophoto-resolution: 1, pc-classify: true, pc-filter: 0, pc-geometric: true, pc-quality: high, pc-sample: 0.01, resize-to: -1, use-3dmesh: true, verbose: true


Average GSD: 5.15 cm
Area: 125,907.68 m²
Reconstructed Points: 6,497,875

This one is tough since there are two halves to the survey with a large gap between them, preventing proper reconstruction when issued together.

Average GSD: 1.97 cm
Area: 839,611.74 m²
Reconstructed Points: 59,185,166


Average GSD: 1.43 cm
Area: 284,244.59 m²
Reconstructed Points: 55,192,844


Average GSD: 1.94 cm
Area: 354,546.92 m²
Reconstructed Points: 38,270,174

Fundamentally though, water is a tough thing to reconstruct. You might be better flying higher, you might be well served by increased overlap and sidelap… Maybe a circular polarizer to reduce spectral reflections from the water surface a bit…

I do think ODM v2.8.0 did a bit better with the reconstruction by not smearing things around, so that’s good!

1 Like

Wow, THX! It does look much better with the smearing on the edge. But also opens up more questions for me.

  1. are these necessary?

dem-gapfill-steps: 4, dem-resolution: 1, dsm: true, dtm: true

Basically, dsm and dtm is not my target of interest so there are a few flag and options I’ve never touched. would adding the dsm and dtm requirement here improve the orthophoto output? Cuz my previous understanding of these two flags is just to generate a dsm/dtm output. With or without it wouldn’t really affect the ortho output

  1. with the mesh setting:

mesh-size: 300000, use-3dmesh: true

I’ve always been using --fast-orthophoto since I do have limited computation power (4 core, 32 GB RAM). Now I start thinking if I got the whole mesh concept wrong previously as the document here use-3dmesh — OpenDroneMap 3.1.7 documentation says 3d mesh is actually faster than 2.5d. I always thought mesh is related to 3d model and if I don’t need one then I don’t need to change these. Even if the higher value may give better ortho, but a faster, less computationally heavy fast ortho would be an acceptable trade off.

  1. I’ve never thinking of reducing matcher-neighbors to 0, I thought having it pre-match the surrounding images would help and save time. Why would you try to use this setting?

matcher-neighbors: 0

  1. Similarly with mesh, I tried really hard to keep my computer alive before therefore I was very hesitant to change the default value (especially to use larger values) of min-num-features and pc* flags. And my previous understanding that all of the following flags would need a really beefy computer. what is your computer or cloud setting to use all these flags then.

min-num-features: 64000, pc-classify: true, pc-filter: 0, pc-geometric: true, pc-quality: high, pc-sample: 0.01, resize-to: -1

**It’s really long post and a sunday morning typing, apologize if some of the sentences look funny. :sweat_smile:


Nope! If you don’t need them you don’t need them. They’re just part of a Processing Parameter Preset I made for general usage.

Fast Orthophoto can help with some low-overlap datasets, and is more than adequate for flat areas. Again, this is just a preset I throw at tough datasets. It likely can use some adjusting…

3D mesh can make some orthophoto features better, but others not. I default to it on, but it can cause problems with built environments.

Normally I would not do this, but I did since this dataset was difficult and I wanted to try and match every image possible. It makes it take incredibly long, though I likely could have done --matcher-neighbors 32 or something similar and had similar effects.

I’m using WebODM Lightning for this, so I’m a lot less shy than I am on my own computer, which like yours, is 32GB RAM and 4 cores / 8 threads.

Mostly trying to get the most features possible, and the densest point cloud possible to ensure the ortho comes out as best it can.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.