Locating images in reconstructions
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 3.8k
- Forks
- 899
- PR merge metrics
- No merged PRs in 30d
Description
It may be useful to have an ability to find images in a reconstruction without adding them to the reconstruction. a) You may believe the existing reconstruction is already plenty accurate b) Opensfm becomes slow with large reconstructions due to bundle adjust/loading large files
Assuming no-one else makes this for me in the next week, I will implement this in some form. I don't think there is a beautiful way of just slipping this in the code - either I will have to make adjustments to lots of functions, so that they can understand how to locate images but not add them. Or I will need to duplicate code.
Would this be a useful function of opensfm as a whole? If yes, I'll go for a more intrusive solution, if not, I'll try and do a more hacky external solution (since I'd rather not have to have my own version of opensfm). Any ideas for clean ways to do this? (general idea I think would be that I would calculate features, ideally only match with images in reconstruction, although probably cost of matching with the other images to be located may be small, then add them to a new tracks file (rather than overwriting), and then locate them in reconstruction by using bundle_single_view function).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the existing feature calculation and matching flow, the tracks file handling, and the mentioned bundle_single_view function. The issue does not name specific files or tests, so first map where reconstruction images are added and where new images are located. Done means locating images without adding them to the existing reconstruction and writing results to a new tracks file.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- computer-vision
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100