Using OpenSFM with a telescopic lens
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- python
- Domain
- computer-vision
Research direction
The issue names no source file, test, or entry point. Start by locating the camera override handling and reconstruction initialization, then reproduce the runs with and without overrides using the telescopic-lens images. Done would require a confirmed way to handle the long focal length and recover accurate real-world measurements.
Written by the indexing model from the issue text.
Description
I have a set of images which were taken with a telescopic lens, with a very large focal length. The object I am imaging is several kilometers away.
The images do not have any exif metadata attached to them. When I run with no camera model overrides, the reconstruction is performed fairly well - the relative shape and camera position appear to agree well with predicted results. However, this does not produce accurate measurements in real-world units since the focal length is estimated much too low at ~0.92. Unfortunately, when I run with camera overrides (with the actual focal length), the reconstruction cannot be performed since there are no image pairs recognized.
I fear that some prior being used is starting the reconstructed camera position at an estimated distance of a few meters from the object, when the true camera position should be several kilometers from the object. Is there any prior I can override to provide an initial estimated camera position which is more accurate for my long focal length?
- Dominant language
- Python
- Stars
- 3.8k
- Forks
- 898
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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.
More from mapillary/OpenSfM
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Potential compatibility issues with matplotlib.cm.get_cmap (Incompatible with Matplotlib 3.9.0)Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
The streetOpen
Difficulty 5/5 Over a week Newbie friendliness 10/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Issue with ODMOpen
Difficulty 4/5 3-5 days Newbie friendliness 35/100
All issues in mapillary/OpenSfM
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 60/100
521xueweihan/HelloGitHub#3924 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
wilbowes/EchoMuse#869 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
namespace operations
Difficulty 1/5 Under an hour Newbie friendliness 72/100
EclipseFdn/open-vsx.org#14043 ·
Maintainers usually reply within 1 day
-
test: TestServeUntilStale races the server's close against the client's sendall (BrokenPipeError under load)Possibly taken @evoludigit claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 89/100
Maintainers usually reply within 1 day