docs icon indicating copy to clipboard operation
docs copied to clipboard

dem-resolution info unclear (also???)

Open jwingnut opened this issue 3 years ago • 10 comments

On this page for dem-resolution (float) https://github.com/OpenDroneMap/docs/blob/publish/source/arguments_edit/dem-resolution.rst it says:

DSM/DTM resolution in cm / pixel. Note that this value is capped by a ground sampling distance (GSD) estimate. To remove the cap, check --ignore-gsd also. Default: 5

It is not clear how to remove the cap. It says "also" but also implies that there is a first action.

What value should be put in the dem-resolution (float) box to remove the cap?

jwingnut avatar Feb 17 '22 01:02 jwingnut

There isn't a value to put into the box to remove the cap, really.

Instead, if one does not also use --ignore-gsd, the value put into --dem-resolution can not exceed the calculated GSD of the reconstruction.

So, if your reconstruction is 4.33cm/px (12MP @ 400ft AGL), and you put in --dem-resolution 1.0 it will not exceed 4.33cm/px.

If however, you also pass --ignore-gsd with --dem-resolution 1.0 it will now be uncapped and will interpolate the 4.33cm/px data to 1.0cm/px.

Saijin-Naib avatar Feb 17 '22 02:02 Saijin-Naib

@jpwhitney , does what I wrote help?

I am working my way around to every parameter to hopefully address concerns like this, so I want to be sure that if I use/rework what I have above it'd be suitable, and you'd look at the updated pages and go "Yeah, makes sense".

Saijin-Naib avatar Feb 18 '22 02:02 Saijin-Naib

Okay so to get the maximum possible orthophoto resolution (not greater than the GSD of the original photos), I could leave --ignore-gsd unchecked and put in 0 for --dem-resolution?

jwingnut avatar Feb 19 '22 00:02 jwingnut

Okay so to get the maximum possible orthophoto resolution (not greater than the GSD of the original photos), I could leave --ignore-gsd unchecked and put in 0 for --dem-resolution?

It has to be greater than 0.0 for local processing (and greater than 1.0 for Lightning), but you could do 0.01 for both --dem-resolution and --orthophoto-resolution with --ignore-gsd false to get the maximum calculated GSD, providing it isn't finer than 0.01cm/px as per above example.

Saijin-Naib avatar Feb 19 '22 00:02 Saijin-Naib

Okay great, thanks for that information.

jwingnut avatar Feb 19 '22 19:02 jwingnut

I just came across this thread (https://community.opendronemap.org/t/setting-gsd/8619/7) which indicates that --dem-resolution doesn't operate as expected, and the resizing image parameter needs to be turned off as well (although I've tried restarting from orthophoto and it doesn't change the GSD). Maybe I'm not restarting from the correct location in the processing? Also more generally, what benefit does listing parameters in alphabetical order have? It seems more logical to group the parameters by their functional usage vs alphabetically.

edit: tried rerunning it from odm_meshing with these options: Options: dem-resolution: 1, fast-orthophoto: true, rerun-from: odm_meshing, resize-to: -1 Average GSD: 2.28 cm Area: 154,065.61 m² Reconstructed Points: 524,738

Still just getting 4.99cm pixels in the orthophoto. Is it possible to get the full 2.28cm without completely restarting?

Tried these options: Options: dem-resolution: 1, fast-orthophoto: true, rerun-from: openmvs, resize-to: -1

Still no change in GSD. Structure from Motion took about 10hrs so I'd rather not redo that if possible (especially without knowing that anything will be changed).

jwingnut avatar Feb 28 '22 08:02 jwingnut

It'll be best to start a new task with the Image Resizing disabled. Once they are resized, only the resized images are used for processing and you can't get back the un-resized imagery.

Saijin-Naib avatar Feb 28 '22 13:02 Saijin-Naib

It'll be best to start a new task with the Image Resizing disabled. Once they are resized, only the resized images are used for processing and you can't get back the un-resized imagery.

Interesting, so although the matching is based on the resized image there is no way to resize the resized matches? It seems like this would be an extreme advantage and time saver if it was possible. Of course it would be at a trade-off of the any surface accuracy, but for simply a high resolution orthophoto this would be a game changer in terms of speed of processing. Do the matching at low res, then construct the orthophoto at full resolution.

Maybe I’m not understanding the results of matching but wouldn’t it be possible to just enlarge the matched regions (in a reverse process to the original scaling)?

jwingnut avatar Feb 28 '22 17:02 jwingnut

Also this question and issue ties back to the difficulties of understanding how changes in parameters impact the final result. If I change a setting I cannot tell what steps will need to be redone.

It seems like some changes will necessitate that the entire process be restarted (from load images) while others do not. It would be awesome to have a flag or warning that would inform the end user about consequences of the change, in terms of where to restart from.

jwingnut avatar Feb 28 '22 17:02 jwingnut

Do the matching at low res, then construct the orthophoto at full resolution. The matching resolution is controlled by --feature-quality.

The Resize Images option you can toggle on/off when creating the task changes the resolution of the images that are uploaded into nodeODM for processing, and will therefore be the maximum resolution available for the rest of processing.

So in your case, if you want maximum potential GSD and Orthophoto, you should not Resize Images, but instead use --feature-quality to work off of resized images for matching only.

Saijin-Naib avatar Feb 28 '22 17:02 Saijin-Naib