Pinhole Camera Estimators

`DLTPointCorrespondencePinholeCameraEstimator’s algorithm is the camera-matrix analogue of the 2D homography DLT described on the transformation-estimators page, and HZ presents it that way too: chapter 7 opens by remarking that estimating "is evident" to be the same problem as chapter 4’s homography estimation, "the only difference [being] the dimension of the problem" (§7.1, p.178). Concretely, each 3D↔2D point correspondence \$\mathbf{X}_i \leftrightarrow \mathbf{x}_i\$ gives the relation (HZ eq. 7.1), of which only 2 of the 3 rows are independent, exactly as in the homography case (HZ eq. 7.2, p.179):

where are the rows of stacked into a 12-vector . Stacking this block for every correspondence gives the design matrix whose null-space (smallest right singular vector, proof) is :

DLT solves for the whole camera matrix with no assumption about its internal structure — 11 free parameters, no more, no less. HZ frames exactly the opposite case, where extra knowledge about the camera is available, as restricted camera estimation (§7.3, p.184): "If additional constraints apply to the matrix P, such as that the pixels are square, then a restricted camera matrix subject to these constraints may be estimated." Its own list of "common assumptions" reads almost like a specification for this hierarchy’s two remaining algorithms: "(i) The skew s is zero. (ii) The pixels are square. (iii) The principal point is known. (iv) The complete camera calibration matrix K is known" — and HZ adds, of the most restrictive case, that "the internal parameters can be computed directly, without necessitating estimating P" (§7.1, p.178, cross-referencing what was then chapter 8). EPnP and UPnP are exactly this idea, made concrete for `PinholeCamera’s factorization ] (Pinhole Camera):

Both are still wrapped by the standard five robust algorithms ({RANSAC|LMedS|MSAC|PROSAC|PROMedS}EPnPPointCorrespondencePinholeCameraRobustEstimator and the UPnP equivalents), and both inherit the same MIN_NUMBER_OF_POINT_CORRESPONDENCES = 6 minimal sample as DLT — even though EPnP’s own formulation is usually stated as needing as few as 4 general (non-coplanar) points. This library standardizes all point-correspondence camera algorithms on the same minimal-sample size for consistency, rather than exploiting EPnP/UPnP’s theoretically smaller minimum.

WeightedPointCorrespondencePinholeCameraEstimator and WeightedLinePlaneCorrespondencePinholeCameraEstimator solve the same DLT-style linear system as above, but scale each correspondence’s rows by an externally supplied per-sample double[] weights (larger weight, more influence on the fit) before the SVD solve, and use a com.irurueta.numerical.robust.WeightSelection helper to pick and sort only the top-N weighted correspondences rather than using all of them (WeightedPointCorrespondencePinholeCameraEstimator.java:25,38-64).

This is precisely HZ’s weighted least-squares normal-equation problem (Appendix A5.2.1, p.591): instead of minimizing the plain algebraic error equally over every row, weighting minimizes it in a norm defined by a positive-definite matrix (in the simplest, and this library’s, case a diagonal matrix of per-correspondence weights):

so a row’s weight enters the problem exactly as a diagonal entry of , scaling that row’s contribution to the normal equations before they are solved — concretely, in this library, by directly multiplying each correspondence’s two design-matrix rows by (a monotonic function of) its weight before the SVD step, rather than forming explicitly. HZ’s own Result A5.1 (p.591) is the special case (equal weights) reducing to the ordinary pseudo-inverse , the same pseudo-inverse already cited on Pinhole Camera for Camera.backProject(Point2D, Point3D).

Neither of these two algorithms has a robust wrapper — there is no RANSACWeightedPointCorrespondence…​ class anywhere in the package (verified: ls src/main/java/com/irurueta/geometry/estimators/ | grep -i weighted returns only the two non-robust classes above). This is intentional, not an oversight: weighting is a deterministic way to favor correspondences you already trust more (e.g. from a better feature-matching score), whereas RANSAC/LMedS/MSAC/PROSAC/PROMedS solve the different problem of not knowing in advance which correspondences to trust at all (estimators.adoc#non-robust-vs-robust). The two ideas are not combined in this library; PROSAC/PROMedS’s qualityScores mechanism (below) is the closest thing to "weighting" that does have a robust wrapper, and it biases sampling order, not the linear system’s row scaling.

Section §2.5.2 "Robust camera estimation using RANSAC" of Alberto Irurueta’s PhD thesis (printed pp.75-77) works out the RANSAC iteration-count formula from first principles, independently of — but arriving at the same result as — HZ’s eq. 4.18. Using for the probability a single correspondence is an inlier and for the minimal sample size, the probability that all points in one random sample are inliers is , so the probability of finding at least one outlier-free sample within trials is ; setting this to a desired confidence and solving for gives (PHD eq. 2.130-2.132):

which is exactly eq. 4.18 with and  — the same formula, derived independently by the same author who wrote this library’s RANSACDLTPointCorrespondencePinholeCameraRobustEstimator. The thesis also notes explicitly (its own words) that "although the DLT algorithm can be used with as many s points as we want (with a minimum of s=6)…​ in order to obtain the smallest possible number of iterations M…​ we will always choose the smallest possible value for s" — the same minimal-sample principle that motivates every hierarchy on this site.

Every concrete {RANSAC|LMedS|MSAC|PROSAC|PROMedS}DLTPointCorrespondencePinholeCameraRobustEstimator scores a candidate camera by reprojecting each 3D point through it and measuring pixel distance to the observed 2D point — a true geometric residual, exactly like the transformation estimators in Transformation Estimators and unlike the algebraic residuals in Conic and Quadric Estimators:

The PhD thesis additionally folds in cheirality (Pinhole Camera) directly into the inlier test — its own Algorithm 2.1 classifies a correspondence as an inlier only if its reprojection error is below threshold and the world point is in front of the camera. The library’s computeResidual above does not itself check cheirality (it is a pure distance), but PinholeCamera.getCheirality/getDepth are available separately for a caller who wants that same combined test (Pinhole Camera).

Full citations are in the bibliography. In detail:

The classes exercised by the code examples above, with links to their source and Javadoc: