Transformations

In any projective frame of , the points with homogeneous last coordinate form a plane, the plane at infinity . In a frame that is already affine (or metric, or Euclidean) it takes the canonical form

(PHD eq. 1.118; HZ eq. 3.1-analogue for 3-space). This is exactly the constant returned by Plane.createCanonicalPlaneAtInfinity(). Under an arbitrary projective transformation, however, moves like any other plane — the library’s own rule applies to it too, and in an arbitrary projective frame it can be anywhere: 3 vanishing points fix 3 independent directions, and the plane they span identifies where actually sits in that frame (PHD fig. 1.9). This is exactly what plane-at-infinity.svg below illustrates: on the left, a cube seen through an uncalibrated homography, where 3 vanishing points mark 3 points of ; on the right, the same cube after upgrading to the affine stratum, where those vanishing points have moved back out to infinity and the cube’s edges are visibly parallel again.

Claim (PHD eq. 1.121-1.123; HZ Result 3.7): a projective transformation fixes as a set if, and only if, it is an affinity. Write a general affine transformation in the library’s own block form (the exact shape produced by AffineTransformation3D.toProjective(), see below):

Applying the plane-transform rule directly to the canonical (PHD eq. 1.121):

so is a fixed point of , and hence (taking inverse-transposes, PHD eq. 1.123) also of the library’s covector rule . Notice this is set-invariance, not pointwise invariance: individual points within  — i.e. individual directions/vanishing points — are free to move around, as long as they stay on the plane. The converse (any projective H that fixes as a set must have a last row proportional to , i.e. must be affine) is HZ Result 3.7, proved the same way the 2D analogue (Result 2.17) is: fixing a hyperplane algebraically forces the homography’s action on the complementary coordinate to vanish.

This is also precisely how you find the affine upgrade once has been identified in an arbitrary projective frame: any matrix of the form

(PHD eq. 1.125, with the first 3 coordinates of the identified , scaled so its last coordinate is 1 — PHD eq. 1.126) sends that plane back to its canonical position, because its last row is . Any with non-singular works equally well (PHD eq. 1.127) —  is simply the simplest choice.

Fixing buys parallelism but says nothing about angles: an affine map can still skew a square into an arbitrary parallelogram. To pin down angles, both HZ and PHD start from the elementary fact that two vectors are orthogonal iff their dot product vanishes, (PHD eq. 1.143-1.144). Pushing that relation through an arbitrary homography gives (PHD eq. 1.145-1.148):

and is symmetric, i.e. exactly the shape of a conic transformed by the library’s own rule with in the metric frame. Running the same argument in 3D with planes and their director vectors (PHD eq. 1.154-1.158) shows that the analogous quadric that certifies orthogonality of planes in a metric frame is degenerate —   — because the extra row/column that would encode a translation-like term must vanish for perpendicularity to be translation-independent.

These two constants are, respectively, the absolute conic and the dual absolute quadric : the point conic that lies on (formed by intersecting the absolute quadric ), and the degenerate quadric whose tangent planes are exactly the planes tangent to (PHD §1.4.3.1, fig. 1.12). In a metric frame:

(PHD eq. 1.160/1.162/1.169; HZ eq. 3.21/3.24 — identical constants). Algebraically is a conic of purely imaginary points, i.e. a "circle" of imaginary radius (PHD eq. 1.163, fig. 1.14); is the limit of an ever-more-squashed sphere as (PHD eq. 1.168, fig. 1.15; HZ calls this a "rim quadric" — picture an ellipsoid squashed to a pancake, with as its rim). These are exactly the shapes absolute-conic-quadric.svg below depicts.

Claim (PHD Proof 1.6, eq. 1.170-1.178; HZ Result 3.9/3.10): a projective transformation fixes (equivalently , up to the overall scale any projective quantity is defined up to) if, and only if, it is a similarity. Sufficiency is a direct computation: writing a similarity in the library’s block form (matching `EuclideanTransformation3D.toMetric()’s output shape) and applying the dual-quadric transform rule (the library’s own forward-forward rule for duals) gives

using for any rotation (PHD eq. 1.170-1.173) — i.e. is reproduced up to the scalar , which is exactly the "up to scale" sense in which any projective entity is defined. For necessity, take an arbitrary projective and demand :

Matching this against (up to the scalar discussed above) forces

(PHD eq. 1.177). So  — the projective row that would otherwise move  — must vanish, and must be a scaled rotation (the condition is exactly "orthogonal up to a positive scalar"). That leaves precisely

a similarity transformation (PHD eq. 1.178) — and since sits in the top-left minor of (PHD eq. 1.166), a transformation that fixes fixes (and hence ) too. HZ Result 3.10 gives the equivalent block-matrix proof for directly, and Result 3.9 proves the corresponding statement for itself by first invoking Result 3.7 (any transformation fixing a conic on must first fix , hence be affine) and then showing the affine part must be orthogonal up to scale.

Because affine upgrade only needs while metric upgrade needs / as well, the two upgrades compose. Combining (eq. 1.125) with the affine→metric matrix that Cholesky-factors the recovered conic out of the affine-stratum dual quadric (PHD eq. 1.179-1.184) gives a single projective→metric matrix (PHD eq. 1.185-1.186):

Inverting it (PHD eq. 1.189-1.192, via blockwise matrix inversion) and substituting into the dual-quadric transform rule shows that in any projective frame (PHD eq. 1.193-1.195):

i.e. the dual absolute quadric in an arbitrary projective frame packages both the dual image of the absolute conic (the "DIAC" that reappears in camera calibration, see Pinhole Camera) and the direction of the plane at infinity into a single symmetric matrix. This is why, in self-calibration literature, recovering is treated as the way to upgrade a projective reconstruction straight to metric in one step, rather than recovering and separately.

irurueta-geometry does not ship such a self-calibration/stratified-upgrade estimator — there is no toAffine()/toMetric() on ProjectiveTransformation2D/3D, and no class under com.irurueta.geometry.estimators or com.irurueta.geometry.refiners computes or from image data. What the library does give you is exactly the algebraic building blocks above — the canonical values of , and , and the one-directional Euclidean→metric→affine→projective upgrade chain — so that, given a Plane/Conic/DualQuadric identified by some other means (vanishing points, orthogonal-plane constraints, Kruppa’s equations, etc.), an application can still build the matrices / above by hand.