I have a small square region roughly 120 meters on a side over which I flew three back-to-back flights. This region is relatively flat and rural but includes two ponds, several buildings, some fencing, and a cell phone tower.
All flights were double-grid with front overlap 85% and side overlap 75%.
Mission #1: 230 feet, survey direction 0, camera pitch -90.
Mission #2: 245 feet, survey direction 20, camera pitch -85.
Mission #3: 245 feet, survey direction 160, camera pitch -85.
I used a DJI Mavic Air 2 set to 48MP mode (images were 8000x6000) flying at 2.5 mph with auto-focus on. Cursory visual inspection of all 278 photos shows nothing out of the ordinary (i.e., no horizon shots, etc.) but some minor changes in lighting were observed due to clouds blocking the sun at different points in time. The images themselves have been uploaded to DroneDB: mathuin/20220414-center-area for the curious, and I’m happy to upload any other product that will help with the issue.
The images were processed with ODM 2.8.2 (tip of master branch as of April 5) compiled locally on an MacBook Pro running macOS 12.3.1 with an M1 Max chip running Docker Desktop 4.7.0 with 8 processors and 48 GB of RAM allocated to Docker. The command line arguments were:
--rerun-all --pc-quality high --ignore-gsd --pc-csv --pc-las --pc-ept --pc-tile --pc-classify --pc-geometric --dtm --dsm --dem-euclidean-map --orthophoto-png --orthophoto-kmz --tiles --build-overviews --time --pc-rectify. The ODM processing took a reasonable amount of time – here is the benchmark file:
dataset runtime: 5.299881 seconds
split runtime: 2.4e-05 seconds
merge runtime: 2e-05 seconds
opensfm runtime: 2709.533958 seconds
openmvs runtime: 2948.958996 seconds
odm_filterpoints runtime: 53.467494 seconds
odm_meshing runtime: 223.551807 seconds
mvs_texturing runtime: 1439.270936 seconds
odm_georeferencing runtime: 351.206476 seconds
odm_dem runtime: 400.56708 seconds
odm_orthophoto runtime: 41.066727 seconds
odm_report runtime: 60.617345 seconds
odm_postprocess runtime: 6.5e-05 seconds
The quality report shows all three missions on top of each other, as expected. The previews look reasonable: the orthophoto is nice, the DSM includes the trees and buildings while the DTM does not, and the big pond’s surface looks odd which always seems to happen.
The survey data section is a big red blot, with empty spots for the big pond and the tops of trees. After looking at the source code (specifically
./stages/odm_report.py), I found that the survey data image is from
./opensfm/stats/overlap.png, which results from a
gdaldem run against
./opensfm/stats/overlap.tif, which itself is generated from a
pdal translate command using the point cloud file as input – and that’s where the trail stops.
Why is the value always 2? Shouldn’t three double-grid overflights result in mostly 5+ values? What am I doing wrong, and is it on the processing side or the data collection side?