pierotofy
commented
2 years ago Choosing sensible defaults is an ambiguous problem; on one hand we could prioritize quality, or we could prioritize speed, or memory usage, but not all of them.
Should ODM generate the best quality output possible as a default?
That means we would need to bump min-num-features, pc-quality and feature-quality (probably others too). What's a good default for "high quality" anyway? Ok you get the point :)
I think the current default of 5 is good because it (usually) gets stuff processed within a decent amount of time without failing with out of memory errors. It strikes a good balance of speed/memory vs quality.
But here's more reasons to keep "lower quality" defaults:
- New users trying ODM for the first time are going to care mostly about just one thing: can the software produce a map (any map). An error of any sort (including out of memory errors) are discouraging and could mean the end of their ODM journey.
- Existing users that might have developed automated pipelines might have certain expectations about defaults; we try to never break existing behavior, unless there's a compelling reason to do so. (Notice we keep around flags like
resize-to, which are now replaced byfeature-quality, but they guarantee backward compatibility). I suppose we try to follow some of the similar rules as the Linux's kernel, one of which is that we "don't break user space" (in our case it's "we don't break app integrations"). We don't always succeed of course, but we try.
I think WebODM could be a better place to change the default parameters, but I would be conservative, even bumping it to 2 will already quadruple the amount of memory texturing will take! That's why WebODM has a High quality preset. So even though you've helped people with good computers get higher resolution maps, you've potentially crippled people get any map at all with lower hardware.
Interestingly for Lightning (https://webodm.net), this issue of perceived low quality due to incorrect orthophoto-resolution / dem-resolution parameters has come up before, and Lightning doesn't (generally) have troubles with memory since we control the environment, and that's why the defaults on Lightning are actually different, if you don't specify an orthophoto-resolution parameter, the default is actually already 2 (as shown from the dashboard's Web UI):
So when processing a task using Lightning, using the Default preset in WebODM, you're getting an orthophoto at 2 cm/px resolution if you process with Lightning.
I think it would be interesting to explore approaches to choose automatic defaults based on both the input data and the running environment (how large are the input images and how much memory do I have), so that the software could adjust dynamically to choose better defaults when no parameters are specified, but profiling memory usage across platforms and coming up with good heuristics (guesses) is not too easy.
Saijin-Naib
--orthophoto-resolution 1.0cm/px as default to match finest supported by Lightning, --dem-resolution 2.0cm/px to follow suggested best-practice of DEM being 1/2 to 1/4 of GSD.
This is prompted by numerous customer conversations stemming from confusion about output quality with Default processing profile in WebODM (or in the case of CLI, no parameters passed at all).
I would appreciate feedback on this change in terms of hardware requirement viability, processing time viability, appropriateness of changing the default here vs in the default processing profiles shipped with WebODM, whether or not --dem-resolution should track changes to --orthophoto-resolution 1:1 instead of 1:0.5 (or 1:0.25), etc.