-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dem-resolution info unclear (also???) #135
Comments
There isn't a value to put into the box to remove the cap, really. Instead, if one does not also use So, if your reconstruction is 4.33cm/px (12MP @ 400ft AGL), and you put in If however, you also pass |
@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". |
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. |
Okay great, thanks for that information. |
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: Still just getting 4.99cm pixels in the orthophoto. Is it possible to get the full 2.28cm without completely restarting? Tried these options: 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). |
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)? |
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. |
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 |
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?
The text was updated successfully, but these errors were encountered: