Closed Saijin-Naib closed 1 year ago
pierotofy
commented
1 year ago Mm, if we increase the resolution, we need to make sure that it doesn't affect the radius. There was a reason the scaling factor was a multiple #914 and I think any benchmark should be done with defaults (e.g. no pc-quality: ultra, because most folks will not process with that).
Saijin-Naib
commented
1 year ago I'll redo a few more tomorrow on bog-standard Defaults and re-assess and post here. Thanks!
smathermather
commented
1 year ago Mm, if we increase the resolution, we need to make sure that it doesn't affect the radius. There was a reason the scaling factor was a multiple #914 and I think any benchmark should be done with defaults (e.g. no
pc-quality: ultra, because most folks will not process with that).
I wrote 914 and it was true for the time. Much like the closed source world, our point cloud is orders of magnitude better now, and I agree with @Saijin-Naib that the ceiling (but not the default) should reflect that. As such, the benchmark for quality improvements shouldn't be defaults. Nor should the only way to bypass this now when exceeding the defaults is with the unwise use of ignore-gsd.
A pull request to address this could be simple, i.e. remove gsd_scaling or set to 1.0, or be more sophisticated and change that value based on pc-quality.
smathermather
commented
1 year ago Simplest possible test here: https://github.com/OpenDroneMap/ODM/pull/1609
Easy to refine and improve and does not change the default behavior (though we probably want to clean up "unused" variable in the form of a dem scaling factor.
Saijin-Naib
commented
1 year ago Settings for Old_Orchard:
Options: auto-boundary: true, dsm: truev3.0.4:
v3.0.4 1:1 GSD Patch:
PointCloud for Feature Reference:
Saijin-Naib
commented
1 year ago Settings for O'Brien's:
Options: auto-boundary: true, dsm: truev3.0.4:
v3.0.4 1:1 GSD Patch:
PointCloud for Feature Reference:
pierotofy
commented
1 year ago I think I'm seeing more smoothing? That's probably due to the decrease in dem-resolution which consequently affects radius_steps, not necessarily because of GSD scaling.
Saijin-Naib
commented
1 year ago Yeah, on O'Brien's especially that seems to be the case with the bee-boxes on the far East of the field, but with Old_Orchard the 1:1 GSD patch was much better at picking up details in the field like the canopy footprints of the individual apple trees to the East, the drainage tile piping piles in the East, the various roof levels on the farmstead to the West, etc.
The positive improvement seems to echo what I observed with Brighton Beach as well, where separation between the planted islands and the roadway was improved and smaller features such as the stones lining the roadway and the wash-out channels in the drainage ditch being much more enhanced.
I'm going to see if I can make it on my Desktop when processing helenenschacht, given the significantly higher-quality data it is comprised of compared to my two datasets from Martin Farms (which were my first collects ever, so I made about every error and bad-practice possible).
I guess the question might become how do we tune radius_steps now?
How did you install ODM? (Docker, installer, natively, ...)?
Docker, but this affects all platforms
What is the problem?
Currently, we cap DEM products to 2x the GSD of the dataset.
What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.
The main historical reasons for this have been to more accurately reflect the precision of our reconstruction, and to help keep resource consumption for this part of the pipeline under control.
I believe that at this point, with all the incredible work to reconstruction completeness, precision, accuracy, multi sub-resolution depthmaps, geometrically consistent depthmaps, rolling shutter correction, enhanced filtering, etc. that we no longer need to cap the DEM products to 2x dataset GSD, and that in fact, we are ready to have DEM products able to be created at 1:1.
How can we reproduce this? What steps did you do to trigger the problem? If this is an issue with processing a dataset, YOU MUST include a copy of your dataset AND task output log, uploaded on Google Drive or Dropbox (otherwise we cannot reproduce this).
Brighton Beach Road -v3.0.4
I'm seeing a significant increase in real resolved detail with @smathermather patch.
Resource consumption is slightly higher, but I've not fully profiled it.
I think that we can change our defaults for dem-resolution to 10cm/px to mimic the behavior of the current pipeline, while allowing folks who tune that parameter to get the full benefit of our improved processing pipeline.