[Refactor]: Deduplicate Homography Computations across kornia-apriltag and kornia-3d
#724 opened on Feb 21, 2026
Repository metrics
- Stars
- (675 stars)
- PR merge metrics
- (PR metrics pending)
Description
🚀 Feature Description
Currently, there are two separate implementations of homography computation within the repository, located in different crates with varying implementations and dependencies:
-
kornia-apriltaguses a custom Gaussian elimination solver implemented directly for f32 vectors incrates/kornia-apriltag/src/utils.rshomography_compute -
kornia-3dusesfaer(an external linear algebra dependency) to perform SVD/LU decomposition for f64 arrays acrosshomography_4pt2dandhomography_4pt3dincrates/kornia-3d/src/pose/homography.rs -
This duplication of mathematical primitives leads to inconsistent behavior, increased maintenance burden, and slightly heavier compile times due to differing linear algebra solvers (custom logic vs. faer).
📂 Feature Category
Other
💡 Motivation
Encountered this duplication problem whilst refactoring kornia-apriltag on issue #676, @cjpurackal has suggested to look into this
💭 Proposed Solution
Centralize homography estimation logic into the core kornia-algebra crate. The new centralized functions should expose an API using glam types (Mat3F32, Mat3F64, Vec2F32), which are the standard geometric types provided by kornia-algebra and are already relied upon heavily by crates like kornia-apriltag.
Under the hood, kornia-algebra can map these to solving backends (like nalgebra or an optimized internal solver) but the public API will remain perfectly interoperable with the rest of the ecosystem.
Possible way to resolve this
-
New Module in
kornia-algebra: Add a newhomographymodulecrates/kornia-algebra/src/linalg/homography.rs. This will provide a robust solver for computing homographies from 4 point correspondences, exposing APIs usingglamtypes:- Implement
homography_4pt2d_f32(returningMat3F32). - Implement
homography_4pt2d_f64andhomography_4pt3d_f64(returningMat3F64).
- Implement
-
Refactor
kornia-apriltag:- Remove
homography_computefromcrates/kornia-apriltag/src/utils.rs - Update
Quad::update_homographiesincrates/kornia-apriltag/src/quad.rsto use the new unifiedhomography_4pt2d_f32method fromkornia-algebra, completely retaining its compatibility with the existingMat3F32operations.
- Remove
-
Refactor
kornia-3d:- Remove the local
homography_4pt2dandhomography_4pt3dimplementations fromcrates/kornia-3d/src/pose/homography.rs - Update callers to use the centralized
kornia-algebrafunctions, adapting from raw[[f64; 2]; 4]types toglamvectors/matrices as necessary. This additionally decouplekornia-3dfrom usingfaerjust for small matrix decompositions directly.
- Remove the local
Additional considerations
- This refactor will require extensive regression testing, perhaps adding new tests and benchmarks
📚 Library Reference
Not applicable
🔄 Alternatives Considered
No response
🎯 Use Cases
If this refactor is to be successful, it will tie kornia-algebra, kornia-apriltag and kornia-3d and make the overall ecosystem more consistent and will result in an easier to use public API.
📝 Additional Context
Issue #678 can be referenced for this refactor.
🤝 Contribution Intent
- I plan to submit a PR to implement this feature
- I'm requesting this feature but not planning to implement it