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:
"--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
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.
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
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.
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 all.zip export for each task? It will help me with the settings you used for each one.
joanlyq-JOB575:
This one is tough since there are two halves to the survey with a large gap between them, preventing proper reconstruction when issued together.
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!
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
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.
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
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.
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.
