WebODM to DroneDeploy comparison - ortho is spot on, holes in 3d model

[Bradley_Thomas]

Hi all,

I am making a tutorial on how to create a relatively simple workflow from drone flyover, to processing via Webodm Lightning, through to client interaction with WebODM through virtual server. I plan on uploading this tutorial to Youtube and I am nearly complete.

A challenge I am facing is trying to get my 3d model up to a satisfactory standard. On the way I plan ondoing comparisons to other software too, but for the time being I am comparing to Drone Deploy.

Link to images - (Sample Photos - Google Drive)

Using Firefox99 and windows 10 NT10.0 Hosting WebODM through Vultr on Ubuntu 20.04

uuid:7186aeaa-1d5e-43e1-b389-e044edbc3f91
“processingTime”:1549828,“status”:{“code”:40},
“options”:[{“name”:“mesh-size”,“value”:300000}
,{“name”:“mesh-octree-depth”,“value”:11}
,{“name”:“pc-sample”,“value”:0.01},
{“name”:“dsm”,“value”:true},
{“name”:“dem-resolution”,“value”:2},
{“name”:“orthophoto-resolution”,“value”:1},
{“name”:“optimize-disk-space”,“value”:true},
{“name”:“pc-ept”,“value”:true},
{“name”:“cog”,“value”:true}],“imagesCount”:123,“progress”:100}
[INFO] auto_boundary: False
[INFO] boundary: {}
[INFO] build_overviews: False
[INFO] camera_lens: auto
[INFO] cameras: {}
[INFO] cog: True
[INFO] copy_to: None
[INFO] crop: 3
[INFO] debug: False
[INFO] dem_decimation: 1
[INFO] dem_euclidean_map: False
[INFO] dem_gapfill_steps: 3
[INFO] dem_resolution: 2.0
[INFO] depthmap_resolution: 640
[INFO] dsm: True
[INFO] dtm: False
[INFO] end_with: odm_postprocess
[INFO] fast_orthophoto: False
[INFO] feature_quality: high
[INFO] feature_type: sift
[INFO] force_gps: False
[INFO] gcp: None
[INFO] geo: None
[INFO] gps_accuracy: 10
[INFO] ignore_gsd: False
[INFO] matcher_neighbors: 8
[INFO] matcher_type: flann
[INFO] max_concurrency: 8
[INFO] merge: all
[INFO] mesh_octree_depth: 11
[INFO] mesh_size: 300000
[INFO] min_num_features: 10000
[INFO] name: 7186aeaa-1d5e-43e1-b389-e044edbc3f91
[INFO] optimize_disk_space: True
[INFO] orthophoto_compression: DEFLATE
[INFO] orthophoto_cutline: False
[INFO] orthophoto_kmz: False
[INFO] orthophoto_no_tiled: False
[INFO] orthophoto_png: False
[INFO] orthophoto_resolution: 1.0
[INFO] pc_classify: False
[INFO] pc_csv: False
[INFO] pc_ept: True
[INFO] pc_filter: 2.5
[INFO] pc_geometric: False
[INFO] pc_las: False
[INFO] pc_quality: medium
[INFO] pc_rectify: False
[INFO] pc_sample: 0.01
[INFO] pc_tile: False
[INFO] primary_band: auto
[INFO] project_path: /var/www/data
[INFO] radiometric_calibration: none
[INFO] rerun: None
[INFO] rerun_all: False
[INFO] rerun_from: None
[INFO] resize_to: 2048
[INFO] sfm_algorithm: incremental
[INFO] skip_3dmodel: False
[INFO] skip_band_alignment: False
[INFO] skip_orthophoto: False
[INFO] skip_report: False
[INFO] sm_cluster: None
[INFO] smrf_scalar: 1.25
[INFO] smrf_slope: 0.15
[INFO] smrf_threshold: 0.5
[INFO] smrf_window: 18.0
[INFO] split: 999999
[INFO] split_image_groups: None
[INFO] split_overlap: 150
[INFO] texturing_data_term: gmi
[INFO] texturing_keep_unseen_faces: False
[INFO] texturing_outlier_removal_type: gauss_clamping
[INFO] texturing_skip_global_seam_leveling: False
[INFO] texturing_skip_local_seam_leveling: False
[INFO] texturing_tone_mapping: none
[INFO] tiles: False
[INFO] time: False
[INFO] use_3dmesh: False
[INFO] use_exif: False
[INFO] use_fixed_camera_params: False
[INFO] use_hybrid_bundle_adjustment: False
[INFO] verbose: False

Orthophoto comparison
WebODM

DroneDeploy

3D Model Comparison
WebODM

DroneDeploy

What is strange, is the blacked out areas have definitely been shot as seen in the below photos. My camera spread should have captured enough common points for alignment.

Some solutions I have found around the forums include:

mesh_octree_depth (11) and depthmap-resolution (2000)
set camera_lens to brown
texturing_data_term: area
texturing_keep_unseen_faces: True
texturing_skip_hole_filling: True
–min-num-features (default 12000) 64000
–feature-quality ultra
–matcher-neighbors 32
-resize_to: -1

Is it best to apply these once at a time and re-iterate each time? This will cost a fair amount of credits on Lightning but I am keen to solve the issue I am facing.

My goal is to create a preset template of settings in WebODM Lightning that I should change every time I need to create a model, and it will produce a satisfactory 3d model.

Thanks for your time.

[Gordon]

Does the DD 3D model have textures applied, but the WebODM is just point cloud?

[Bradley_Thomas]

It seems that the points are not registering in the cloud, guessing that it has not been able to successfully identify common points to align which is strange, I thought the flight path I have is very thorough. I can see in the output_text file there is matching occuring between these image filenames in the processes, so if this is occuring, I’m wondering why there isn’t any data there. Hmm.

I might try another iteration and change some features, will update this post as I go.

[Bradley_Thomas]

What other edits can I make in the parameters to make it clearer? I think it is close to being presentable, but as you can see points aren’t registering on the front of the house. Strange.

Options: auto-boundary: true, camera-lens: brown, dsm: true, matcher-neighbors: 32, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 20000, pc-quality: high, resize-to: -1, texturing-data-term: area, texturing-keep-unseen-faces: true

[INFO] auto_boundary: True
[INFO] boundary: {}
[INFO] build_overviews: False
[INFO] camera_lens: brown
[INFO] cameras: {}
[INFO] cog: True
[INFO] copy_to: None
[INFO] crop: 3
[INFO] debug: False
[INFO] dem_decimation: 1
[INFO] dem_euclidean_map: False
[INFO] dem_gapfill_steps: 3
[INFO] dem_resolution: 2.0
[INFO] depthmap_resolution: 640
[INFO] dsm: True
[INFO] dtm: False
[INFO] end_with: odm_postprocess
[INFO] fast_orthophoto: False
[INFO] feature_quality: high
[INFO] feature_type: sift
[INFO] force_gps: False
[INFO] gcp: None
[INFO] geo: None
[INFO] gps_accuracy: 10
[INFO] ignore_gsd: False
[INFO] matcher_neighbors: 24
[INFO] matcher_type: flann
[INFO] max_concurrency: 24
[INFO] merge: all
[INFO] mesh_octree_depth: 12
[INFO] mesh_size: 300000
[INFO] min_num_features: 15000
[INFO] name: 863864e0-5a96-440e-bd68-73e552188ec2
[INFO] optimize_disk_space: True
[INFO] orthophoto_compression: DEFLATE
[INFO] orthophoto_cutline: False
[INFO] orthophoto_kmz: False
[INFO] orthophoto_no_tiled: False
[INFO] orthophoto_png: False
[INFO] orthophoto_resolution: 2.0
[INFO] pc_classify: False
[INFO] pc_csv: False
[INFO] pc_ept: True
[INFO] pc_filter: 2.5
[INFO] pc_geometric: False
[INFO] pc_las: False
[INFO] pc_quality: high
[INFO] pc_rectify: False
[INFO] pc_sample: 0.01
[INFO] pc_tile: False
[INFO] primary_band: auto
[INFO] project_path: /var/www/data
[INFO] radiometric_calibration: none
[INFO] rerun: None
[INFO] rerun_all: False
[INFO] rerun_from: None
[INFO] resize_to: 2048
[INFO] sfm_algorithm: incremental
[INFO] skip_3dmodel: False
[INFO] skip_band_alignment: False
[INFO] skip_orthophoto: False
[INFO] skip_report: False
[INFO] sm_cluster: None
[INFO] smrf_scalar: 1.25
[INFO] smrf_slope: 0.15
[INFO] smrf_threshold: 0.5
[INFO] smrf_window: 18.0
[INFO] split: 999999
[INFO] split_image_groups: None
[INFO] split_overlap: 150
[INFO] texturing_data_term: area
[INFO] texturing_keep_unseen_faces: True
[INFO] texturing_outlier_removal_type: gauss_clamping
[INFO] texturing_skip_global_seam_leveling: False
[INFO] texturing_skip_local_seam_leveling: False
[INFO] texturing_tone_mapping: none
[INFO] tiles: False
[INFO] time: False
[INFO] use_3dmesh: False
[INFO] use_exif: False
[INFO] use_fixed_camera_params: False
[INFO] use_hybrid_bundle_adjustment: False
[INFO] verbose: False

[Saijin_Naib]

Hmm…

Maybe increase --feature-quality and --pc-quality to ultra, set --pc-filter to 0

[Bradley_Thomas]

Thanks Saijin, I’m processing through WebODM Lightning so I am not sure if ultra is possible, it only shows ‘high’ in the drop down. I’ve updated a couple of other settings, lets see how we go!

[Saijin_Naib]

Ahhh, yeah, no ultra on Lightning, just high, as you’ve noted.

[Bradley_Thomas]

Back at it again, I think I’ve reached the limit of 3d model reconstruction with WebODM (so far), and I would like to say it is quite impressive.

Processing Node: Lightning (manual)

Options: camera-lens: brown, dem-resolution: 1, matcher-neighbors: 32, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 64000, orthophoto-resolution: 1, pc-filter: 0, pc-quality: high, pc-sample: .01, resize-to: -1, texturing-data-term: area, texturing-keep-unseen-faces: true

Average GSD: 0.53 cm

Area: 3,150.1 m²

Reconstructed Points: 30,035,115

While WebODM is able to produce a viable alternative to many of the leading photogrammetry apps at a fraction of the price, it does still have a fair way to come to reach being ‘presentable to client’. It would perhaps suit a hobbyist or inhouse operations.

I am going to run some more tests using Pix4D, Agisoft and post to this thread, keep your eye out. Any further ideas to increase the reliability of the model, let me know!

B

[Bradley_Thomas]

Suprisingly PIX4D results are worse off…

Seriously weird stuff going on with the roof here!

[Gordon]

I’ve had a couple of goes at this dataset, also with less than ideal results.

There aren’t any intermediate height AGL images to tie the high photos to the low ones of the side of the house. I think there just aren’t enough common features to tie them all together into a good mesh. Also, I notice that focus is rather poor on the photos taken from high up, so finding good points that tie in with the photos of the sides of the house is always going to be even more difficult.

[Red Cedar Lane - 16/04/2022](javascript:void(0)
122images 01:46:17
|Processing Node:|node-odm-1 (auto)|
|Options:|auto-boundary: true, feature-quality: ultra, gps-accuracy: 8, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 12000, orthophoto-resolution: 1, pc-classify: true, pc-filter: 0, pc-geometric: true, pc-quality: ultra, pc-rectify: true, resize-to: -1, texturing-data-term: area, texturing-keep-unseen-faces: true, use-3dmesh: true|
|Average GSD:|0.88 cm|
|Area:|3,092.06 m²|
|Reconstructed Points:|43,226,039|

[smathermather]

@Bradley_Thomas

While WebODM is able to produce a viable alternative to many of the leading photogrammetry apps at a fraction of the price, it does still have a fair way to come to reach being ‘presentable to client’. It would perhaps suit a hobbyist or inhouse operations.

It’s a little early to draw that conclusion, and a bit dismissive. FOSS projects, like OpenDroneMap can be (and is in our case) a commercial endeavor and professional tool. Indeed, given the subsidization via parent companies and/or VC funding of some of our closed-source competition, there’s a high probability that OpenDroneMap is among very few projects in the space that have a functional business model (Piero jokes it’s the only profitable photogrammetry tool).

That doesn’t mean it is the best tool for your use case: that’s a different matter altogether. However, if we assume that your drone GPS coordinates have a relative accuracy of ~0.2 meters, and turn the knobs up on features, we get some substantially better results:

Because of the roof overhang, a better meshing model than what we use in OpenDroneMap would be ideal, but for now, this is probably as good as we can make it in WebODM. If your relative GPS error is anticipated to be lower, even better results can be achieved, but I would hazard that this is near the limit of what we can do at this time with your dataset.

[Bradley_Thomas]

Thank you for both of your solutions Smathermather and Gordon. I didn’t mean to sound dismissive, ODM is a great piece of software.

I’m interested in making it operate in the way you have smathermather. Can I confirm why you would change the GPS Accuracy to 0.2m considering the P4P only has consumer grade accuracy with its on board GNSS module? My following question would be, can I reduce this even further to obtain the extra data you seemed to have been able to grab, and instead use ground control points tied to my local projected datum (I am a surveyor so I can provide this information for WebODM) for its relative positioning?

Could you send your text output file so I can have a look at the settings? Super interested.

I had decided that WebODM was the only option available, the other softwares are just too pricey.

[YanNoun]

I’m curious to know if it’s the features knob or the gps-accuracy knob ?

In any case, it is super impressive, and it convinces me that the initial SfM point cloud is super important for the dense processing : OpenMVS starts by meshing the initial SfM cloud to initial depth and visibilities, so I wonder if we could run SfM with moderate number of features to get SfM solution, then we re-extract a crazy amount of features, and match “just” match what we need in order for the dense to be happy.

[smathermather]

@YanNoun

I’m curious to know if it’s the features knob or the gps-accuracy knob ?

The noise in the roof model, completeness, and evenness was addressed by increasing min-num-features to 80000. Probably didn’t need to be that high, but I figured it wouldn’t hurt and it reduced overall noise and increased completeness quite nicely (ht your recent post, YanNoun).

@Gordon

I think there just aren’t enough common features to tie them all together into a good mesh.

Gordon is right: there isn’t enough overlap between the high images and low images. Some match and tie in, but not all.

Which leads us to GPS accuracy:

Setting gps-accuracy to 0.2 ensured that the multiple models generated in reconstruction would remain well-enough aligned, thus filling in the missing portions below the roof of the building.

@Bradley_Thomas

Can I confirm why you would change the GPS Accuracy to 0.2m considering the P4P only has consumer grade accuracy with its on board GNSS module?

Well, this is the interesting part. When we use GPS accuracy, we don’t really distinguish between accuracy and consistency. But, even for an airborne commodity GNSS device, we should expect sub-meter, even decimeter consistency within short windows of time, even if the absolute accuracy isn’t anywhere near that high. It might be interesting to add a feature which looks at the range of dates and times in a dataset, and estimates a GNSS consistency, rather than a static 10m assumption. This is likely something that DD is doing (plus some good estimation of planar surfaces in their meshing, of course).

@Bradley_Thomas

I’m interested in making it operate in the way you have smathermather.

This is the full set of settings, though gps-accuracy and min-num-features should get you most of the way there:

auto-boundary: true, dsm: true, gps-accuracy: .2, matcher-neighbors: 200, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 80000, orthophoto-resolution: 1, pc-geometric: true, pc-quality: ultra, rerun-from: dataset, resize-to: -1

[israelbar]

@Bradley_Thomas

While WebODM is able to produce a viable alternative to many of the leading photogrammetry apps at a fraction of the price, it does still have a fair way to come to reach being ‘presentable to client’. It would perhaps suit a hobbyist or inhouse operations.

It depends on the use case, for instance we were using pix4d and agisoft in an industrial enviroment (mining) and after a long testing process now we can use opendronemap. But we tipically take the resulting products (Orthophoto, point cloud and DEMs) into different software to continue processing. So products must be accurate and readable by the software, and there is not interest in making them ready for a client as a final product. So I agree, opendronemap is great for in-house operations.

We also noted that we must adapt the flight to opendronemap requirements, wich are different from pix4d and agisoft, tipically with higher overlaping between images. Model quality is controlled mostly by the flight plan and resulting images.

You may have better results increasing overlaping, adjusting contrast and increasing image dynamic range in order to get more information in areas under the shadows.

Also, to get more details in the roof and walls, you can increase GSD by flying at lower altitud or resizing images. I have used Topaz Gigapixel with good results.

@Bradley_Thomas

I had decided that WebODM was the only option available, the other softwares are just too pricey.

Dont give up, it will work for you as it is working for thousand other users.

[Bradley_Thomas]

I don’t know if it’s because -pc quality cannot be set to high but I’ve tried using the following settings and still can’t get it to refine quite like yours. It could be because I’m using WebODM

Is it possible to download ODM to my instance on Vultr and process the dataset through that? That way I should be able to select PC quality Ultra, correct? Trying to find a solution

Options: camera-lens: brown, dem-resolution: 1, gps-accuracy: .2, matcher-neighbors: 200, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 80000, orthophoto-resolution: 1, pc-filter: 0, pc-geometric: true, pc-quality: high, pc-sample: .01, resize-to: -1, texturing-data-term: area, texturing-keep-unseen-faces: true

I’m going to do another re run using texturing-data-term: gmi instead of area.

If this one doesn’t eventuate my options will be;

-redo flyover runs at 90 degree nadir, one with gimble at 10 degree tilt and then another on a 20 degree rotation, and then close up photos

-look to running ODM locally (this will mean the purchase of a new computer)

[CallmeDash]

G’Day,

I just downloaded your dataset to have a go at processing it and couldnt help notice they were taken down the Shoalhaven. Im just starting out in photogrammetry and based out of Wollongong. Just wanted to say Hi and look forward to reading your future findings.

Dash

[Gordon]

I too am familiar with the location, my aunty lives just down the mountain in Berry

[Bradley_Thomas]

I’ve decided that I’ll do another flyover at my earliest convenience to properly use Webodm.

Since then I’m working on another flyover that involves using GCP’s. Check my other posts for more info