mirror of
https://github.com/opencv/opencv.git
synced 2026-09-11 12:52:33 -05:00
8104037c60
video: accept CV_Bool masks in findTransformECC (#25895) #29681 ### Problem `cv::Mat_<bool>::depth()` returns `CV_Bool` in 5.0, where it returned `CV_8U` in 4.x. `findTransformECCWithMask` does not type check `inputMask` at all. It passes it straight to `cv::threshold()` at `ecc.cpp:483`, and `cv::threshold()` dispatches only on `CV_8U`, `CV_16S`, `CV_16U`, `CV_32F` and `CV_64F`, erroring otherwise. So a boolean mask fails with an error pointing at imgproc rather than at the mask: ``` modules/imgproc/src/thresh.cpp:1607: error: (-210:Unsupported format or combination of formats) in function 'cv::threshold' ``` ### Fix Widen a `CV_Bool` mask to `CV_8U` before the `threshold` call. The existing `THRESH_BINARY` step then treats any non-zero entry as selected, which matches the `CV_8U` mask semantics. `inputMask` is used nowhere else in the function (only at `ecc.cpp:476` for the `empty()` check and at `:483`), so this is the single point that needed handling. `CV_8U` masks take an unchanged path. Note that `cv::computeECC` already accepts a boolean mask, because it only forwards the mask to `countNonZero`, `meanStdDev` and `subtract`, which all handle `CV_Bool`. This change makes `findTransformECC` consistent with it. ### Test `Video_ECC_BoolMask.matches_uchar_mask` builds a blurred checkerboard, warps it by a known translation, then runs `findTransformECC` with `MOTION_TRANSLATION` using a `Mat_<bool>` mask and the equivalent `CV_8UC1` mask, and requires the same warp matrix from both. Verified locally on 5.x: the test fails without the change (with the error above) and passes with it. The full `*ECC*` set, 15 tests, passes with `OPENCV_TEST_DATA_PATH` set. No test data needed for the new test itself, it is synthetic. Part of #25895, and follows the same approach as #29580, #29597 and #29622. ### Pull Request Readiness Checklist - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch - [x] There is a reference to the original bug report and related work - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name. - [x] The feature is well documented and sample code can be built with the project CMake