Hi,
Today i tried WebODM on the same dataset but everytime i received a different one. Some times that orthophoto quality was good but some times they were bad.
Do anyone have any idea?
I’m using webodm_node-odm_1 version 2.8.0
1 Like
Best to share a link to the dataset for diagnosis. Cheers!
2 Likes
Some aspects of the pipeline aren’t deterministic (especially feature extraction and matching) so you can see variability.
This can be mitigated to some degree by increasing a few quality parameters here and there.
Also, to echo Stephen, dataset and parameters (and screenshots of what you’re seeing) are incredibly helpful 
2 Likes
Thank you for reply
Here is my options
‘auto-boundary’: True,
‘dsm’: True,
‘feature-quality’: ‘ultra’,
‘feature-type’: ‘hahog’,
‘min-num-features’: 18000,
‘pc-quality’: ‘low’,
‘optimize-disk-space’: True,
‘ignore-gsd’: True
And this is my dataset
2 Likes
This one can cause tons of issues. Please don’t use it and re-try your dataset.
Also, the orthophoto is heavily influenced by the pointcloud quality, so you likely want to improve this:
1 Like
As you said, I changed option but orthophoto is still bad.
And one more thing is that when I run WebODM on different PC with webodm_node-odm_1 version 2.7.2, orthophoto was good all the time.
Is there anything matter with node odm version?
Below are results from 2 PC.
The good one
The bad one
2 Likes
What parameters did you use for both? Do you have the Report PDFs and/or console logs?
The parameters that i used on webodm_node-odm_1 version 2.7.2 was the one i sent before
‘auto-boundary’: True,
‘dsm’: True,
‘feature-quality’: ‘ultra’,
‘feature-type’: ‘hahog’,
‘min-num-features’: 18000,
‘pc-quality’: ‘low’,
‘optimize-disk-space’: True,
‘ignore-gsd’: True
Its report is here
Otherwise, the parameters that i used on webodm_node-odm_1 version 2.8.0 is
auto-boundary: true,
dsm: true,
feature-type: hahog,
ignore-gsd: true,
min-num-features: 18000,
optimize-disk-space: true,
pc-quality: low
And its report is here
2 Likes
To make sure the same parameters was run, i rerun webodm_node-odm_1 version 2.8.0 with the same parameters that i run on webodm_node-odm_1 version 2.7.2 that the orthophoto was good. And here is the report.
2 Likes
Did pretty decent here:
auto-boundary: true, crop: 0, debug: true, dem-gapfill-steps: 4, dem-resolution: 0.01, dsm: true, dtm: true, feature-quality: ultra, gps-accuracy: 1, matcher-neighbors: 32, mesh-octree-depth: 12, mesh-size: 300000, min-num-features: 64000, orthophoto-resolution: 0.01, pc-classify: true, pc-filter: 0, pc-geometric: true, pc-quality: ultra, pc-rectify: true, pc-sample: 0.001, resize-to: -1, use-3dmesh: true, verbose: true
2 Likes
Nice result with latest Windows build -
196images 00:10:37
|Processing Node:|node-odm-1 (auto)|
|Options:|dem-resolution: 1, feature-quality: ultra, gps-accuracy: 2, matcher-neighbors: 12, mesh-octree-depth: 12, mesh-size: 250000, orthophoto-resolution: 1, pc-classify: true, pc-filter: 0, pc-geometric: true, pc-quality: ultra, pc-rectify: true, resize-to: -1, use-3dmesh: true|
|Average GSD:|7.37 cm|
|Area:|17,097.22 m²|
|Reconstructed Points:|2,668,787|
2 Likes
There’s really something going on between 2.7 and 2.8 : everything looks fine when looking at the report (features, matching, camera model).
Could you share a dataset ?
3 Likes
Thank you Saijin_Naib and Gordon for helping me out.
I tried your options and orthophoto’s quality is still not good as the one I ran on version 2.7.2. You will see some missing parts in middle of orthophoto.
So I’m thinking of what matter here is odm’s version.
And below I will summarize my options and results on different odm version.
Options:
auto-boundary: true,
dsm: true,
feature-type: hahog,
ignore-gsd: true,
min-num-features: 18000,
optimize-disk-space: true,
pc-quality: low,
feature-quality: ultra
Results
ODM version 2.7.2:
Report: version-2.7.2-good.pdf - Google Drive
ODM version 2.8.0
Report: version-2.8.0-bad.pdf - Google Drive
YanNoun
Here is my dataset
2 Likes
Can you please post your full processing logs for both v2.7.2 and v2.8.0?
I’m wondering if your instance is using the GPU feature matching/extraction or not, or if something else is going on.
2 Likes
Here they are
3 Likes
I think we may have found our culprit…
300 images in the dataset processed under v2.7.2, 196 images processed under v2.8.0.
Less images means you’ll likely have to push the various quality settings higher, like I did, to get the same quality of reconstruction.
2 Likes
I only used 196 images in Windows WebODM, with ODM 2.8.0
2 Likes
Yep! And both you and I pushed a number of important quality and feature/matching parameters much higher, which likely compensated for the lower image density compared to the 300 image dataset.
2 Likes
I re-ran it with HAHOG, but no appreciable difference… but I didn’t ignore-gsd! 
2 Likes
Oh sorry I sent wrong file.
The right log of version 2.7.2 is here
2 Likes