kornia/kornia-rs

[Refactor]: Deduplicate Homography Computations across kornia-apriltag and kornia-3d

Open

#724 opened on Feb 21, 2026

View on GitHub
 (3 comments) (0 reactions) (1 assignee)Rust (188 forks)auto 404
enhancementhelp wantedtriage

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-apriltag uses a custom Gaussian elimination solver implemented directly for f32 vectors in crates/kornia-apriltag/src/utils.rs homography_compute

  • kornia-3d uses faer (an external linear algebra dependency) to perform SVD/LU decomposition for f64 arrays across homography_4pt2d and homography_4pt3d in crates/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

  1. New Module in kornia-algebra: Add a new homography module crates/kornia-algebra/src/linalg/homography.rs. This will provide a robust solver for computing homographies from 4 point correspondences, exposing APIs using glam types:

    • Implement homography_4pt2d_f32 (returning Mat3F32).
    • Implement homography_4pt2d_f64 and homography_4pt3d_f64 (returning Mat3F64).
  2. Refactor kornia-apriltag:

    • Remove homography_compute from crates/kornia-apriltag/src/utils.rs
    • Update Quad::update_homographies in crates/kornia-apriltag/src/quad.rs to use the new unified homography_4pt2d_f32 method from kornia-algebra , completely retaining its compatibility with the existing Mat3F32 operations.
  3. Refactor kornia-3d:

    • Remove the local homography_4pt2d and homography_4pt3d implementations from crates/kornia-3d/src/pose/homography.rs
    • Update callers to use the centralized kornia-algebra functions, adapting from raw [[f64; 2]; 4] types to glam vectors/matrices as necessary. This additionally decouple kornia-3d from using faer just for small matrix decompositions directly.

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

Contributor guide