Found 2026-08-03 while auditing warpAffine/warpPerspective/remap-based methods for OpenCV 4/5 numeric-drift issues (see #44). `tests/test_image_reshape.py`'s `test_warp`, `test_warp_affine`, `test_warp_perspective`, `test_undistort`, and `test_interp2d` are all empty stubs (`# Add test cases for the decimate method` / `pass`) -- zero real assertions, for five distinct methods in `ImageReshape.py` that wrap `cv2.warpAffine`/`cv2.warpPerspective`/`cv2.remap`/`cv2.undistort`.
`test_rotate` (same file) does have real coverage and was specifically checked against a real OpenCV 5.0.0.93 install as part of #44 -- its one exact-equality assertion (`rotate(0)`, an identity transform) is confirmed safe on both versions, no drift. But the five methods above have no coverage at all to check.
Fix
Write real tests for each: a known input + expected transform (e.g. `warp_affine` with a translation matrix, `undistort` with known distortion coefficients on a synthetic pattern), asserting geometric correctness with a tolerance rather than exact pixel equality -- OpenCV's own migration notes describe revised interpolation between versions 4 and 5, so any assertion here should tolerate small numeric drift by construction, not just by accident.
Found 2026-08-03 while auditing warpAffine/warpPerspective/remap-based methods for OpenCV 4/5 numeric-drift issues (see #44). `tests/test_image_reshape.py`'s `test_warp`, `test_warp_affine`, `test_warp_perspective`, `test_undistort`, and `test_interp2d` are all empty stubs (`# Add test cases for the decimate method` / `pass`) -- zero real assertions, for five distinct methods in `ImageReshape.py` that wrap `cv2.warpAffine`/`cv2.warpPerspective`/`cv2.remap`/`cv2.undistort`.
`test_rotate` (same file) does have real coverage and was specifically checked against a real OpenCV 5.0.0.93 install as part of #44 -- its one exact-equality assertion (`rotate(0)`, an identity transform) is confirmed safe on both versions, no drift. But the five methods above have no coverage at all to check.
Fix
Write real tests for each: a known input + expected transform (e.g. `warp_affine` with a translation matrix, `undistort` with known distortion coefficients on a synthetic pattern), asserting geometric correctness with a tolerance rather than exact pixel equality -- OpenCV's own migration notes describe revised interpolation between versions 4 and 5, so any assertion here should tolerate small numeric drift by construction, not just by accident.