core: gate GEMM SIMD off on 32-bit x86 and macOS-x64 (5.x) #29496
- this is port of https://github.com/opencv/opencv/pull/29242 to 5.x branch
- GEMM SIMD is turned off on 32-bit x86 and macOS-x64 to fix calibration
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [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
- [ ] 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
imgproc: accept CV_Bool masks in matchTemplate (#25895) - #29677
### Problem
`cv::Mat_<bool>::depth()` returns `CV_Bool` in 5.0, where it returned `CV_8U` in 4.x. `matchTemplateMask` gates the mask at `templmatch.cpp:737`, so passing a boolean mask now fails with:
```
(-215:Assertion failed) _mask.depth() == CV_8U || _mask.depth() == CV_32F in function 'cv::matchTemplateMask'
```
A binary mask is a normal input for masked template matching, so this is a regression against 4.x.
### Fix
Allow `CV_Bool` in the assertion and widen the mask to `CV_8U` before the existing binarization step.
The widening is required rather than passing `CV_Bool` straight through, because `cv::threshold()` does not accept `CV_Bool`. Once widened, the existing `THRESH_BINARY` path treats any non-zero entry as selected, which is exactly the documented `CV_8U` mask semantics. `CV_8U` and `CV_32F` masks take an unchanged path.
The masked path is the only one affected: `cv::matchTemplate` routes every non-empty mask through `matchTemplateMask`, and there is no OpenCL mask variant.
### Test
`Imgproc_MatchTemplateBoolMask.matches_uchar_mask` compares a `Mat_<bool>` mask against the equivalent `CV_8UC1` mask and requires the results to agree, across all six match methods (`TM_SQDIFF`, `TM_SQDIFF_NORMED`, `TM_CCORR`, `TM_CCORR_NORMED`, `TM_CCOEFF`, `TM_CCOEFF_NORMED`) for `CV_8UC1`, `CV_8UC3` and `CV_32FC1` images. 18 parameter combinations.
Verified locally on 5.x: all 18 fail without the source change (with the assertion above) and pass with it. The full `*MatchTemplate*` set, 165 tests, passes. No test data needed, the test 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
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
cv::Mat_<bool>::depth() returns CV_Bool in 5.0, where it was CV_8U in 4.x, so
code that passed a boolean mask to inpaint() stopped working on the 5.x branch.
icvInpaint() rejected anything that was not CV_8UC1, even though CV_Bool is a
single byte like CV_8U and the uchar reads in the fast marching code are already
correct for it. Relaxing the type gate is therefore sufficient, no conversion of
the mask is needed.
The regression test checks a boolean mask against the equivalent CV_8U mask and
requires both the output type and every pixel to match, for both inpainting
algorithms and for 1 and 3 channel input.
Verified locally: the test fails against unmodified 5.x with "The mask must be
8-bit 1-channel image" and passes with the change. The rest of opencv_test_photo
is unaffected.
is_SetHardwareGain's master-gain parameter is documented as 0-100;
out-of-range values are not guaranteed to be handled predictably by
the SDK, so clamp before passing through.
extractChannel() stopped supporting in-place operation (dst aliasing
src) after commit 416bf3253 (PR #23473), which replaced
Mat src = _src.getMat();
_dst.create(src.dims, &src.size[0], depth);
with a single up-front
_dst.createSameSize(_src, depth);
...
Mat src = _src.getMat();
When _src and _dst reference the same array, the up-front reallocation
reshapes the shared buffer to a single channel before the multi-channel
source header is fetched. mixChannels() then sees a 1-channel source and
throws for any coi >= 1.
Move createSameSize() back to after the source Mat/UMat is obtained, so
the source header keeps the original multi-channel data alive across the
destination reallocation. This preserves the 0D/1D handling introduced
by createSameSize while restoring the pre-existing in-place contract.
Adds regression test Core_Mat.extractChannel_inplace_29568.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
