features2d: add missing KAZE DIFF_CHARBONNIER support #28324
### Description
This PR fixes the missing implementation for `DIFF_CHARBONNIER` diffusivity type in KAZE feature detector.
### Changes
- Added `charbonnier_diffusivity()` call for `DIFF_CHARBONNIER` type in `Create_Nonlinear_Scale_Space()`
- Added proper error handling for unsupported diffusivity types
### Problem
When using KAZE with `DIFF_CHARBONNIER` diffusivity type, keypoint coordinates were not computed at subpixel level, because the code lacked the specific handling for this diffusivity mode.
### Solution
The `charbonnier_diffusivity()` function already exists in `nldiffusion_functions.cpp`, it just wasn't being called. This PR adds the missing `else if` branch to call it, matching the pattern already implemented in `AKAZEFeatures.cpp`.
Fixes#27134
### 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 copyleft license.
- [x] The PR is proposed to the proper branch.
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
- [ ] The feature is well documented and sample code can be built with the project CMake
optimize(dnn): parallelize Slice layer implementation (4.x) #28511
### Summary
Backport of PR #28447 to 4.x branch.
### Description
This PR optimizes the SliceLayer implementation for strided inputs (where step > 1). The original implementation used a recursive element-wise copy (getSliceRecursive) for any strided slice, which was extremely inefficient.
This PR introduces:
- **Parallelization**: Uses `cv::parallel_for_` to parallelize the outermost dimension of the slice operation.
- **Memcpy Optimization**: Automatically detects "pseudo-contiguous" blocks in strided slices (e.g., slicing an outer dimension but keeping inner dimensions intact) and uses `std::memcpy` instead of scalar loops.
- **Refactoring**: Replaces the recursive function with a dedicated `ParallelSlice` loop body.
### Impact
Significant performance improvement for strided slice operations (common in detection heads, strided sampling, etc.).
### Benchmark Results
Tested on CPU with 20 threads.
| Test Case | Baseline (ms) | Optimized (ms) | Speedup |
| :--- | :--- | :--- | :--- |
| Strided Axis 0 [::2, ...] | 1.10 | 0.02 | **~55x** |
| Strided Axis 2 [..., ::2] | 1.15 | 0.11 | **~10.5x** |
### 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
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
- [ ] The feature is well documented and sample code can be built with the project CMake
dnn: improve robustness of MVN layer#28308
This change adds small defensive improvements to the MVN layer implementation:
->Guard against zero-sized OpenCL kernel launches
->Add input validation in finalize()
->Use int64 for FLOPS computation to avoid overflow
No functional or performance changes are intended.
### 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
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
imgcodecs: fix integer overflow in BMP and SunRaster decoders #28379
### 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
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Fixes#28350
### Description
This PR fixes integer overflow vulnerabilities in BMP and SunRaster image decoders that could cause heap buffer over-read when decoding malformed images.
### Root Cause
The `src_pitch` and `width3` calculations in `BmpDecoder::readData()` and `SunRasterDecoder::readData()` used `int` arithmetic:
```cpp
int src_pitch = ((m_width * m_bpp + 7) / 8 + 3) & -4;
int width3 = m_width * nch;
```
When `m_width` or `m_bpp` are large values from a crafted malicious file, the multiplication overflows, resulting in a small or negative value. This leads to insufficient buffer allocation, causing heap buffer over-read during subsequent decoding operations.
### Fix
1. **Use `size_t` arithmetic**: Cast operands to `size_t` before multiplication:
```cpp
const size_t bits_per_row = static_cast<size_t>(m_width) * static_cast<size_t>(m_bpp);
const size_t src_pitch_size = ((bits_per_row + 7) / 8 + 3) & ~static_cast<size_t>(3);
```
2. **Add size validation**: Added `CV_CheckLT` to reject images requiring buffers larger than 256MB:
```cpp
const size_t MAX_SRC_PITCH = static_cast<size_t>(1) << 28;
CV_CheckLT(src_pitch_size, MAX_SRC_PITCH, "BMP: src_pitch exceeds maximum allowed size");
```
3. **Safe conversion**: Use `validateToInt()` for safe conversion back to `int`.
### Files Changed
- `modules/imgcodecs/src/grfmt_bmp.cpp` - BmpDecoder::readData()
- `modules/imgcodecs/src/grfmt_sunras.cpp` - SunRasterDecoder::readData()
### Testing
- Code compiles without warnings
- Basic BMP and SunRaster encode/decode tests pass
- Overflow conditions are now properly rejected with CV_CheckLT
hal/riscv-rvv: Fix test failures on hardware that implements tail-agnostic as all 1s #28375
### 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
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
### Summary
Fix test failures in `opencv_test_core` and `opencv_test_imgproc` on hardware that implements the tail-agnostic policy by overwriting tail elements with all 1s
### Root Cause
According to the [RISC-V Vector Extension Specification v1.0](https://github.com/riscvarchive/riscv-v-spec/blob/master/v-spec.adoc#343-vector-tail-agnostic-and-vector-mask-agnostic-vta-and-vma):
> "When a set is marked agnostic, the corresponding set of destination elements in any vector destination operand can either retain the value they previously held, or are overwritten with 1s."
Both `dotProd_32f` and `dotProd_32s` functions use accumulator variables(`s`) that persist across loop iterations, but were using vector intrinsics with tail-agnostic policy. The tail elements can be overwritten with 1s, corrupting the accumulator and producing NaN during the final reduction sum.
### Solution
Changed both functions to use `tail-undisturbed`(`tu`) policy to ensure tail elements remain unchanged across loop iterations.
### Reproduce Steps
The failures can be reproduced using [QEMU](https://gitlab.com/qemu-project/qemu) with `rvv_ma_all_1s=true` and `rvv_ta_all_1s=true` options to emulate hardware implementing tail-agnostic policy as all 1s.
#### Reproduce **`opencv_test_core`** failures:
```
qemu-riscv64 -cpu rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0,rvv_ma_all_1s=true,rvv_ta_all_1s=true -L '/PATH_TO_SYSROOT/sysroot/' ./opencv_test_core --gtest_filter="Core_DotProduct*"
```
Before the patch:
```
[ FAILED ] Core_DotProduct.accuracy (24 ms)
```
After the patch:
```
[ PASSED ] 1 test.
```
#### Reproduce **`opencv_test_imgproc`** failures:
```
qemu-riscv64 -cpu rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0,rvv_ma_all_1s=true,rvv_ta_all_1s=true -L '/workspace/riscv/sysroot/' ./opencv_test_imgproc --gtest_filter="fitLine_Modes.accuracy/*"
```
Before the patch
```
[ FAILED ] 24 tests, listed below:
[ FAILED ] fitLine_Modes.accuracy/0, where GetParam() = (13, 1)
[ FAILED ] fitLine_Modes.accuracy/1, where GetParam() = (13, 2)
[ FAILED ] fitLine_Modes.accuracy/2, where GetParam() = (13, 4)
[ FAILED ] fitLine_Modes.accuracy/3, where GetParam() = (13, 5)
[ FAILED ] fitLine_Modes.accuracy/4, where GetParam() = (13, 6)
[ FAILED ] fitLine_Modes.accuracy/5, where GetParam() = (13, 7)
[ FAILED ] fitLine_Modes.accuracy/6, where GetParam() = (21, 1)
[ FAILED ] fitLine_Modes.accuracy/7, where GetParam() = (21, 2)
[ FAILED ] fitLine_Modes.accuracy/8, where GetParam() = (21, 4)
[ FAILED ] fitLine_Modes.accuracy/9, where GetParam() = (21, 5)
[ FAILED ] fitLine_Modes.accuracy/10, where GetParam() = (21, 6)
[ FAILED ] fitLine_Modes.accuracy/11, where GetParam() = (21, 7)
[ FAILED ] fitLine_Modes.accuracy/12, where GetParam() = (12, 1)
[ FAILED ] fitLine_Modes.accuracy/13, where GetParam() = (12, 2)
[ FAILED ] fitLine_Modes.accuracy/14, where GetParam() = (12, 4)
[ FAILED ] fitLine_Modes.accuracy/15, where GetParam() = (12, 5)
[ FAILED ] fitLine_Modes.accuracy/16, where GetParam() = (12, 6)
[ FAILED ] fitLine_Modes.accuracy/17, where GetParam() = (12, 7)
[ FAILED ] fitLine_Modes.accuracy/18, where GetParam() = (20, 1)
[ FAILED ] fitLine_Modes.accuracy/19, where GetParam() = (20, 2)
[ FAILED ] fitLine_Modes.accuracy/20, where GetParam() = (20, 4)
[ FAILED ] fitLine_Modes.accuracy/21, where GetParam() = (20, 5)
[ FAILED ] fitLine_Modes.accuracy/22, where GetParam() = (20, 6)
[ FAILED ] fitLine_Modes.accuracy/23, where GetParam() = (20, 7)
```
After the patch
`[ PASSED ] 24 tests.`
Fix ~0.5px systematic offset in CharucoDetector subpixel refinement #28380Resolves#25539
### Problem
`CharucoDetector::detectBoard` produces Charuco corner coordinates that are consistently offset by approximately **+0.5 pixels** compared to `findChessboardCorners + cornerSubPix`.
This offset is systematic (mean ≈ −0.5 px when comparing legacy − Charuco) and reproducible across images. Visual inspection also shows that the legacy chessboard detector aligns better with the actual corner locations.
### Root cause
In `charuco_detector.cpp`, the points passed to `cornerSubPix` are manually shifted by `-Point2f(0.5f, 0.5f)` before refinement and then shifted back by `+Point2f(0.5f, 0.5f)` after refinement.
However, `cornerSubPix` refines corners in **absolute image coordinates** and converges to the true saddle point based on image gradients. Shifting the initial guess does not affect the converged result as long as the true corner lies within the refinement window.
The additional `+0.5` shift applied after refinement therefore introduces a constant bias, resulting in:
```
P_out = P_true + 0.5
```
### Solution
Remove the manual `±0.5` coordinate shifts around the `cornerSubPix` call and let the refined result be returned directly.
### Test updates
Updated expected corner values in the following tests:
- `testBoardSubpixelCoords`
- `testSeveralBoardsWithCustomIds`
The previous expected values (e.g. `200`, `250`, `300`) were only correct due to the +0.5px bias introduced by the bug.
`generateImage` creates checkerboard squares of exactly **50 pixels**, which places true corner locations on **pixel boundaries** rather than pixel centers. As a result, the correct subpixel coordinates are:
```
199.5, 249.5, 299.5
```
instead of the previously expected integer values.
After updating the expected values, all **30 Charuco-related tests pass** with the fix applied.
### Verification
I verified the fix using a Python reproducer that compares `CharucoDetector` output against `findChessboardCorners + cornerSubPix`:
- **Before fix:** mean error ≈ −0.501 px
- **After fix:** mean error ≈ −0.001 px
After the change, the Charuco detector output aligns with the legacy chessboard detector both numerically and visually.
### Notes
This change only affects the post-refinement coordinate handling and does not alter detection logic, refinement parameters, or performance.
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
- [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
Fix integer overflow in medianBlur #28386
The bug in #28385 is that the pointer arithmetic in
https://github.com/opencv/opencv/blob/d8bc5b94b851d5b392c61e5b954fba992e18bb73/modules/imgproc/src/median_blur.simd.hpp#L666-L668
overflows if `i*sstep` is larger than `INT_MAX`, because both variables are of type `int`. If one operand is of type `size_t` instead, the other operand gets promoted to `size_t` before multiplication and overflow doesn't happen anymore.
The test allocates 2.3GB for the Mat; I hope that's okay.
This PR fixes#28385
### 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
- [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
The TopK layer was incorrectly rejecting K values equal to the input
dimension size. According to ONNX specification, K should be allowed
to equal the dimension size (to retrieve all elements).
Changed validation from 'K < input_shape[axis]' to 'K <= input_shape[axis]'
This fixes the error when loading YOLOv10 ONNX models that use TopK
with K equal to the dimension size.
Fixes#28445
docs: fix spelling errors in documentation and code #28301
- [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
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
- [ ] The feature is well documented and sample code can be built with the project CMake
### Description
Fixed multiple spelling errors across documentation, comments, and code:
- 'colummn' → 'column' (cublas.hpp, 3 occurrences)
- 'points_per_colum' → 'points_per_column' (calib3d.hpp, 3 occurrences)
- 'Asignee' → 'Assignee' (sift files, 2 occurrences)
- 'compability' → 'compatibility' (face.hpp, 2 occurrences)
- 'orignal' → 'original' (aruco_detector.cpp)
- 'refrence' → 'reference' (chessboard.cpp)
- 'indeces' → 'indices' (stitching.hpp)
- 'OutputPrecison' → 'OutputPrecision' (test)
- 'tranform' → 'transform' (slice_layer.cpp, 3 occurrences)
Total: 24 fixes across 14 files. Documentation and comment changes only, no functional impact.
docs(calib3d): fix grammar and clarify radial distortion formula in camera calibration tutorial #28422
This PR improves the camera calibration tutorial documentation by:
- Fixing minor grammatical issues for better readability.
- Clarifying the radial distortion model by explicitly defining r² = x² + y².
These changes do not affect functionality and are intended to make the mathematical explanation clearer for readers and new users.
Precompute X values in Forney algorithm to eliminate redundant gfPow calls.
Previously, gfPow(2, ...) was computed multiple times for the same error
location across different loop iterations, resulting in O(L²) redundant
Galois field arithmetic operations.
This change:
- Precomputes all X values once before the main loop
- Reduces complexity from O(L²) to O(L) for X value computations
- Removes the TODO comment at line 1642
- No functional changes, only performance improvement
The optimization is most beneficial when there are many error locations
in QR codes (larger L values).
core: add NEON support for cvFloor in fast_math.hpp #28243
- This PR adds NEON intrinsics-based implementation for the cvFloor function in fast_math.hpp for Windows-ARM64.
- Both float and double overloads now use NEON intrinsics for cvFloor Function.
- calchist and calchist1d function uses cvFloor function for its computations.
- After adding these changes both functions showed improvement in performance.
**Performance Benchmarks:**
<img width="956" height="273" alt="image" src="https://github.com/user-attachments/assets/a00c98cd-d245-4d11-a9fd-361a3bd89f59" />
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
imgproc: replace assertion in cornerSubPix with descriptive error #28404
Replace CV_Assert with explicit bounds check for initial corners in cornerSubPix.
This provides a descriptive runtime error instead of abrupt termination,
improving error handling for Python and C++ users.
No algorithmic or behavioral change for valid inputs.
Fixes#25139 (Related to #7276).
### 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
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Fixes#28436.
Replaces a nullptr dereference (unguaranteed to cause a SEGFAULT) by `std::terminate` which will call the current `std::terminate_handler` and then SIGARBT.
Properly preserve KAZE/AKAZE license as mandated by BSD-3-Clause #28441
Close https://github.com/opencv/opencv/issues/28440
### 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
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Alexander Smorkalov
Vincent Rabaud
Igraine
Murat Raimbekov
Hanbin Bae
Kumataro
Karnav Shah
Arnie Chang
Kavyansh Tyagi
Denis Barucic
Siddharth Panditrao
Adrian Kretz
Satge96
Sikandar
Shrutikasri04
Abhishek
pratham-mcw
Luis Adame Rodríguez
Alexander Smorkalov
Nechama Krashinski
Erellu
jinbo