kornia/kornia-rs

🐛 Describe the bug solve_epnp gives a wrong pose even on perfect (noise-free) data when it gets 5 or more points. The cause is an index mismatch on the 4 null-space vectors in crates/kornia-3d/src/pnp/epnp.rs: build_l6x10 reverses the columns, so beta[0] belongs to the smallest-eigenvalue vector (as in the paper and OpenCV) pose_from_betas (null4 * beta) and gauss_newton use the columns in the stored order, where column 0 is the 4th smallest So the initial betas are computed for one order and applied to the other. 🔄 Steps to Reproduce Put the code below in `crates/kornia-3d/tests/epnp_repro.rs` and run: cargo test --release -p kornia-3d --test epnp_repro -- --nocapture 💻 Minimal Code Example use kornia_3d::pnp::{solve_pnp, EPnPParams, PnPMethod}; use kornia_algebra::{Mat3AF32, Vec2F32, Vec3AF32}; #[test] fn epnp_noise_free_is_exact() { let k = Mat3AF32::from_cols_array(&[800.0, 0.0, 0.0, 0.0, 800.0, 0.0, 640.0, 480.0, 1.0]); let t = [0.2f32, -0.1, 5.0]; let worl

🐛 Describe the bug VideoWriter::close() never returns. The program hangs forever. Why: close() does three things in this order: sends "end of stream" to the pipeline stops the pipeline (set_state(Null)) waits for the bus thread to finish The bus thread waits for an "end of stream" message. But step 2 stops the pipeline before that message is sent, so the message never comes. The bus thread waits forever, and close() never returns. 🔄 Steps to Reproduce 1. Create a writer with `VideoWriter::new(...)` 2. Call `start()` 3. Call `write()` a few times 4. Call `close()` → it never returns The existing tests `video_writer_rgb8u` and `video_writer_mono8u` also hang when run with: cargo test -p kornia-io --features gstreamer -- --ignored video_writer 💻 Minimal Code Example use kornia_image::{Image, ImageSize}; use kornia_io::gstreamer::video::{ImageFormat, VideoCodec, VideoWriter}; let size = ImageSize { width: 64, height: 48 }; let mut writer = VideoWriter::new("out.mp4", VideoCo

🐛 Describe the bug DistanceTransformExecutor::execute returns non-zero distances for foreground pixels when the image width or height is greater than 4096. distance_transform_1d computes the parabola intersection as (f[q] + (q * q) as f32) - (f[r] + (r * r) as f32) (crates/kornia-imgproc/src/distance_transform.rs:145). f32 stores integers exactly only up to 2^24 = 4096², so for q > 4096 the squares are rounded. For example, 4097² = 16,785,409 is stored as 16,785,408, which moves the intersection between pixels 4097 and 4098 from 4097.5 to 4098.0, so pixel 4098 is assigned to the wrong parabola. Found by @edgarriba while reviewing #1166. 🔄 Steps to Reproduce 1. Create an all-zero `Image<f32, 1>` larger than 4096 px in width or height (e.g. 7680×4320, 4200×1 or 1×4200). 2. Set the whole first row and first column to 1.0 (foreground). 3. Run `DistanceTransformExecutor::new().execute(&image)`. 4. Every pixel in row 0 and column 0 should have distance 0, but many after index 4097

🐛 Describe the bug I got an error when i run cargo test on my local machine and it said: ---- ba_schur::tests::defaults_are_bit_identical_to_the_frozen_solver stdout ---- thread 'ba_schur::tests::defaults_are_bit_identical_to_the_frozen_solver' (70594) panicked at crates/kornia-3d/src/ba_schur.rs:5868:13: assertion `left == right` failed: walkthrough (sparse=false) digest 0xe291e8283f21d870 != frozen 0x456e57e0017646b6 — a default-parameter solve is no longer bit-identical to the pre-intrinsics solver left: 16326085383750277232 right: 5003032855664019126 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: ba_schur::tests::defaults_are_bit_identical_to_the_frozen_solver 🔄 Steps to Reproduce . 💻 Minimal Code Example ✅ Expected behavior . ❌ Actual behavior . 🔧 Environment - kornia-rs version: 0.2.0 - Rust version: 1.98.1 - Cargo version: 1.98.1 - OS: Linux(Debian 13 trixie): - Target architecture: x86_64 - Python version:

🐛 Describe the bug #1117 notes that HuberLoss::new returns Ok for a NaN delta, and #1155 adds a guard in refine.rs. The constructors in crates/kornia-algebra/src/optim/losses.rs still accept NaN from any other caller: the check is delta <= 0.0 (scale <= 0.0 for Cauchy), which is false for NaN, so the loss is built and every weight() / rho() call returns NaN. 🔄 Steps to Reproduce 1. Add the two tests below to the `tests` module of `crates/kornia-algebra/src/optim/losses.rs` 2. Run `cargo test -p kornia-algebra nan` 3. Both tests fail 💻 Minimal Code Example #[test] fn test_huber_loss_nan_delta_error() { assert!(HuberLoss::new(f32::NAN).is_err()); } #[test] fn test_cauchy_loss_nan_scale_error() { assert!(CauchyLoss::new(f32::NAN).is_err()); } ✅ Expected behavior HuberLoss::new(f32::NAN) and CauchyLoss::new(f32::NAN) return Err, like new(0.0) and new(-1.0) already do. ❌ Actual behavior Both return Ok, so both tests fail: assertion failed: HuberLoss::new(f32::NAN).is_e