Skip to content
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

Documentation Mega-Issue #516

Closed
dakotabenjamin opened this issue Mar 22, 2017 · 12 comments
Closed

Documentation Mega-Issue #516

dakotabenjamin opened this issue Mar 22, 2017 · 12 comments
Projects
Milestone

Comments

@dakotabenjamin
Copy link
Member

dakotabenjamin commented Mar 22, 2017

Use this for suggestions, ideas, complaints, etc. I'll try to compile them all into a list in this top comment.

Ideas for framework

  • Sphinx
  • others?

Content

  • Installation
  • Usage
  • Examples
  • Breakdown of each algorithm/process
  • Hardware requirements
  • Benchmarks
  • assessing accuracy
  • best practice mission and image resolution/settings
    • tradeoff decisions
  • Cameras, camera distortion, etc.
    • EXIF info needed
  • Contributing
    • How Ecto works / how to write using it
    • Where everything is located
  • How to cite ODM
  • Developer bio page

Other thoughts

  • Testing
  • Hosting (opendronemap.org)
  • Maintenance
@pierotofy
Copy link
Member

I'd be happy to see more documentation on how to get hacking with ODM (and in particular to understand the ecto cells). But this is a good list!

@rohitrameshrao
Copy link

rohitrameshrao commented Mar 23, 2017

It would be helpful if we can add some information about hardware usage and recommended hardware.

@smathermather
Copy link
Contributor

Good point. This is a common question, and I have few concrete answers for people.

@hblanken
Copy link
Contributor

Would be great to add best practice mission and image resolution/settings together with a list of camera types with a link to an inventory of matrix.txt and distortion.txt files for each camera type. Clearly there will be must do's and but also recommendations which will vary by use case objective.

@smathermather
Copy link
Contributor

Good call, @hblanken.

@rohitrameshrao
Copy link

I think we also need more information on accuracy. Very critical to know how accurate the reconstruction is.

@dakotabenjamin
Copy link
Member Author

@rohitrameshrao that is a feature currently in the works, hopefully soon.

This was referenced Apr 3, 2017
@pepperlk
Copy link
Contributor

Gonna give some performance input on a few runs of ODM:
Using the odm_data_toledo with a big VM (16 cores 32gb ram) I clocked in at 22 min (avg) across 5 runs
Trying to understand the hardware to processing time ratio..
Ill post more updates as I have time to run tests but I think the performance is very good for this project seeing that mark..
That vm runs at $0.98 hr so decent bang for the literal buck..

@hblanken
Copy link
Contributor

hblanken commented May 2, 2017

Building on @rohitrameshrao and @dakotabenjamin and @pepperlk and @clarkerz comments - It would be really good to build a list or table or other graphical representation of the tradeoff decisions to make to achieve quality/accuracy vs cost/time. I would suggest the quality depends on its horizontal and vertical accuracy. The absolute vertical accuracy of a ODM asset could be measured as the average discrepancy between sample points of ODM and surveyed positions (considered as the reference). Following the theory of normal distribution of errors, the accuracy can be stated at the 1-sigma (68% confidence interval) or 2-sigma (95% confidence) interval.
Now it would be really good to understand how to influence this accuracy via settings/flags.
-original image input pixel - i.e. 4K is often over the top and not needed, 2.7k is sufficient, 1080p could also be enough for many use cases.
-resizing of images to process - is 2400 right? for some use cases 1920 could be okay?
-depth
-matching
-ortho resolution
etc, etc
The objective is to come up with the optimal tradeoff view for running ODM for achiving key use cases. E.g. We could show how to set ODM to achieve a vertical accuracy specification of 0.1m at 2-sigma (2s) means that 95% of the points will be within 0.1m of their true (surveyed) height vs A specification of 0.5m at 1-sigma (1s).

@dakotabenjamin dakotabenjamin added this to In progress in Backlog Mar 17, 2018
@dakotabenjamin
Copy link
Member Author

dakotabenjamin commented Mar 21, 2018

All: http://docs.opendronemap.org is now live!

@hblanken
Copy link
Contributor

Fantastic read - I saw the 'flying tips' section is empty - let me contribute via this comment and make a start:

Please do a final check to ensure a great outcome before you fly and before you start processing:

[ ] Do at least 2 rounds 'Point of Interest' scenes for 3D objects: We recommend to shoot at 5 m/s rotation, shoot one image every 3 sec, resolution at 2.7k is great, 4k is often not needed.
[ ] Ensure the images are all geotagged.
[ ] Add a 'Grid' shot for large areas : We recommend shoot with at least 60% overlap. A rule of thumb at 100m height is one shot every 3 seconds, with 20m/s.
[ ] Images stitch only if there is no sky in the background! So keep at least 45 degree camera angle.
[ ] We recommend 50-500 images, this is often sufficient for most models.

Think of it as a spray can, the more you spray !equally! across your scenery, without gaps, the better the results.

I will think of more to fill the blanks

@smathermather smathermather moved this from In progress to Done in Backlog Dec 14, 2018
@smathermather
Copy link
Contributor

Docs have been substantially written. There's always more to do, but we should refresh with a new issue, as much of this has been addressed or is otherwise no longer an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Backlog
  
Done
Development

No branches or pull requests

6 participants