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

initialize_cameras_landmarks should support per-frame initial intrinsics #1318

Open
mwoehlke opened this issue May 27, 2021 · 3 comments
Open

Comments

@mwoehlke
Copy link

It appears the only way to specify initial intrinsics to a initialize_cameras_landmarks is via the configuration? But this is a problem if the cameras are known to have different intrinsics (e.g. non-uniform image sizes). There should be a way to supply per-frame initial intrinsics, at least for the camera principle point.

@mwoehlke
Copy link
Author

Ah... is sfm_constraints intended for this? Is it safe, then, to set the principal point to any old value? (At least the documentation has an error; it mentions a metadata parameter, but the parameter is actually constraints.)

@mleotta
Copy link
Member

mleotta commented May 27, 2021

The principal point is almost always assumed to be the center of the image and fixed at the center. Estimating a custom principal point for imagery taken from a normal camera is usually overfitting the model unless you have a specialty camera where you know the lens is not centered with the sensor.

That aside, in general it would be good to be able to specify an initial guess for camera intrinsics on each camera. sfm_constraints is more for optimization constraints (e.g. make sure this camera stays close to this GPS location). For initialization I suggest we put the initial guess in the input camera map. We could add a config option that tells the algorithm to only use the intrinsics from those initial guesses.

@mwoehlke
Copy link
Author

Riiiiight... although for my usage I have the unenviable case that my inputs may have been (perhaps even probably have been) cropped, which means the principle point is I-have-no-idea-where. I'd hope I can ignore that, but... that's actually a good question; can I? And, more to the point, if my inputs are of wildly different sizes (say, 200×200 and 2000×2000), am I going to run into trouble not being able to specify a separate principle point for each of those?

It sounds like constraints is not the mechanism for dealing with this?

For initialization I suggest we put the initial guess in the input camera map.

From my (GUI) end this should be pretty straight-forward; in fact, I'd even started writing it that way before realizing this was an issue. I guess this would need changes in KWIVER though? (Hence why I opened the issue...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants