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

RFC: merge fisheye camera into default camera calibration API #11885

Open
wants to merge 1 commit into
base: 4.x
Choose a base branch
from

Conversation

paroj
Copy link
Contributor

@paroj paroj commented Jul 3, 2018

for #11015

  • allow using default calib flags for fisheye functions
  • forwarded the cameraModel flag where possible
  • solvePnP will still fail with fisheye model in undistort points
    • as undistortPoints is in imgproc, while the fisheye version is in calib3d there is no forwarding
  • the ccalib versions could be similarly integrated

@mshabunin mshabunin added the RFC label Jul 16, 2018
@D-Alex
Copy link
Contributor

D-Alex commented Sep 23, 2018

A more object oriented solution would be to generate classes for different camera models and use the classes to proxy the calls to the right underlying base functions. This could be also used for adding more complex camera models like refractive ones. In addition it would hide the complexity for manipulating cameras (move / rotate / map to scene / normalise / canonical / ...).

Also a class like this could be used to replace

class CV_EXPORTS Camera

@paroj
Copy link
Contributor Author

paroj commented Sep 25, 2018

use the classes to proxy the calls to the right underlying base functions

this is probably the cleaner solution as it would alleviate passing on a consistent flags combination.

However I think (3D) move/ rotate should be kept outside to keep Camera focused on projecting things.

In the end it boils down on backwards compatible we want to be. Any opinions on that?

@D-Alex
Copy link
Contributor

D-Alex commented Sep 25, 2018

Changing the pose of a pinhole camera is essentially just manipulating the underlying projection matrix with some helper methods and improves the usability for people not familiar with the 4x3 projection matrix.

I believe in the long run there will be more cameras in opencv than the currently implement ones and adding more flags for this does not really scale. In an ideal world application developers would just use a generic camera interface which gets proxied to the right opencv functions (opencv::fisheye, opencv::pinhole, ....). This would maintain the strength of opencv having base functions with near zero side effects while also giving a common interface for more demanding applications such as Sfm.

camera = new FishEye(...)
camera->calibrate
camera->undistortPoints
camera->estimatePose3D2D --> solvePnP
camera->estimatePose2D2D --> fivePoint algorithm 

@vpisarev vpisarev self-assigned this Dec 2, 2020
@vpisarev vpisarev added this to the 5.0 milestone Dec 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants