Hi, I’m using a Mavic 2 Enterprise Advanced to acquire photos in a forested area. I try to generate an orthophoto and the program crashes every time I upload my photos [“cannot process dataset”]. The program does not work even if I use as few as 6 or 7 photos. The only way I can get an orthophoto is if I use the “fast orthophoto” option. That option is not good enough for my work.
Every photo acquired with the M2EA is around 20 MB. Any suggestions?
How much ram do you have and what’s the overlap?
RAM: 32 GB
Overlap: Approx. 65%-70%
Welcome!
Andreas has a great question.
You can try using the Forestry setting with an increase to high for --feature-quality
and increasing --min-num-features
, --matcher-neighbors
, --matcher-distance
by about 25%.
If it fails again, you may need to investigate increasing the pagefile/swapfile size.
Or try the split option?
I don’t think that would be my recommendation for an early troubleshooting step as it brings in a lot of extra complication and variables to manage, as well as being more finicky to get just right.
Increasing pagefile/swap does not require the user to learn new parameters and how they interplay.
I think windows normally automatically sets the size of the swap file
It uses a formula to determine the max pagefile size (very minimal/conservative), yes, but it can be manually set to give oneself a much higher max allocation address space which can ease Out-Of-Memory issues when processing.
Hi, I followed your suggestion and it did not work. This is what I did:
Feature quality: High
Min num features: 22500
Matcher neighbors: 10
Matcher distance: 10
I used 19 pictures, each 20 MB. The areas I’m covering are small, the size of a pool.
Are you picking 19 images that are sequential so they’d be right next to each other?
Can you please attach the entire processing log?
What type of area is it, forest… urban?
Looks like forested.
The images are right next to each other.
There are too many characters in the log and I’m not allowed to upload the log as a separate file, so this is the last line I got:
===== Done, human-readable information to follow… =====
[ERROR] Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See Flying Tips — OpenDroneMap 3.1.7 documentation
I can send the log via email if it’s ok.
Hi, correct.
In the middle of a forested area there are small ponds called vernal pools. I flew below 100 ft because of all the branches and I had to do this manually. I try my best to follow a symmetric flight path.
I’m taking a guess here with what you’ve said so far, but it seems like we might be having trouble finding sufficient tie points with images taken that low and manually flown, and maybe running up against RAM limits when turning things up…
If you can share the data, I can try locally (also only 32GB RAM).
ok, I’m uploading the 19 images on DroneDB. How can I share that with you afterwards?
You would just copy/paste the link from the dataset view.
It would look something like the below:
https://testhub.dronedb.app/r/saijinnaib/odm_data_brighton_beach
So, hubame.dronedb.app/r/username/datasetname
There you go
https://testhub.dronedb.app/r/benavides/0lurwpdbblqrn9mq
Thanks to all for your time.
Created on: 11/23/2021, 3:11:11 PM
Processing Node: node-odm-1 (manual)
Options: auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 0.1, dsm: true, dtm: true, feature-quality: ultra, feature-type: orb, matcher-neighbors: 0, matcher-type: bruteforce, mesh-octree-depth: 14, mesh-size: 5000000, min-num-features: 15000, orthophoto-resolution: 0.1, pc-classify: true, pc-filter: 1, pc-geometric: true, pc-quality: ultra, pc-rectify: true, pc-sample: 0.01, resize-to: -1, use-3dmesh: true, verbose: true
Average GSD: 0.48 cm
Area: 420.9 m²
Reconstructed Points: 8,423,958
benavides-9607-report.pdf (3.7 MB)
My pagefile settings: