The whole-library audit (docs/performance-audit.md, added in #1033) hit several ops from python that exist in Rust but are unreachable or inconsistently typed from the python surface. Each one is a place where a user has to guess which dtype/channel combination happens to be wired.
Gaps
1. Gaussian pyramids have no python binding at all. pyrdown / pyrup / build_pyramid exist for f32 and u8 on both CPU and CUDA (crates/kornia-imgproc/src/pyramid.rs, cuda/pyramid.rs, plus PyramidPlan) but nothing is exposed in kornia-py. This is the largest coverage hole — a whole op family shipped in the Rust crate and invisible to wheel users.
2. gaussian_blur / box_blur host path is C3-only. A single-channel host Image raises expected 3 channels, got 1, while the device path accepts C1 fine. Same function, different accepted shapes depending on residency.
3. hsv_from_rgb / lab_from_rgb / ycbcr_from_rgb host arms are f32-only. u8 works on device but not on host. Worse, the failure mode is a confusing pyo3 downcast error ('ndarray' object is not an instance of 'ndarray') rather than a dtype message naming the problem.
4. compute_histogram host path takes numpy arrays but not host Images — inconsistent with the rest of the surface, which accepts both.
Suggested direction
- Bind the pyramid family (
pyrdown/pyrup/build_pyramid), residency-dispatched like the other ops, following the kornia-py/src/dispatch.rs pattern; consider exposing PyramidPlan for the allocation-free path.
- Wire the missing host arms for blur C1 and the u8 color conversions (the Rust functions exist; this is dispatch plumbing).
- Where an arm genuinely doesn't exist, make the error message name the dtype/channel mismatch instead of surfacing a raw downcast failure.
Verification
- Python tests per new binding, including a device/host consistency check.
cargo check -p kornia-py with no features (the cfg-gate trap that has broken non-CUDA builds before) in addition to --features cuda.- Re-run
scripts/bench_audit.py — the rows that currently print nan for k-cpu should fill in.
The whole-library audit (
docs/performance-audit.md, added in #1033) hit several ops from python that exist in Rust but are unreachable or inconsistently typed from the python surface. Each one is a place where a user has to guess which dtype/channel combination happens to be wired.Gaps
1. Gaussian pyramids have no python binding at all.
pyrdown/pyrup/build_pyramidexist for f32 and u8 on both CPU and CUDA (crates/kornia-imgproc/src/pyramid.rs,cuda/pyramid.rs, plusPyramidPlan) but nothing is exposed inkornia-py. This is the largest coverage hole — a whole op family shipped in the Rust crate and invisible to wheel users.2.
gaussian_blur/box_blurhost path is C3-only. A single-channel hostImageraisesexpected 3 channels, got 1, while the device path accepts C1 fine. Same function, different accepted shapes depending on residency.3.
hsv_from_rgb/lab_from_rgb/ycbcr_from_rgbhost arms are f32-only. u8 works on device but not on host. Worse, the failure mode is a confusing pyo3 downcast error ('ndarray' object is not an instance of 'ndarray') rather than a dtype message naming the problem.4.
compute_histogramhost path takes numpy arrays but not hostImages — inconsistent with the rest of the surface, which accepts both.Suggested direction
pyrdown/pyrup/build_pyramid), residency-dispatched like the other ops, following thekornia-py/src/dispatch.rspattern; consider exposingPyramidPlanfor the allocation-free path.Verification
cargo check -p kornia-pywith no features (the cfg-gate trap that has broken non-CUDA builds before) in addition to--features cuda.scripts/bench_audit.py— the rows that currently printnanfork-cpushould fill in.