imgcodecs(webp): improve IMWRITE_WEBP_LOSSLESS_MODE to support exact lossless compression #28519Close#28503
Add IMWRITE_WEBP_LOSSLESS_MODE enum to control lossless strategy:
- IMWRITE_WEBP_LOSSLESS_OFF: Lossy compression.
- IMWRITE_WEBP_LOSSLESS_ON: Optimize/drop color in transparent pixels.
- IMWRITE_WEBP_LOSSLESS_PRESERVE_COLOR: Preserve color in transparent pixels.
Note: Currently limited to still images; animated WebP support is deferred per YAGNI.
### 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
[BUG FIX] Incorrect shape assert bug fix in 5.x #28575
Closes: https://github.com/opencv/opencv/issues/28563
### 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
Added GRU layer in new DNN engine #28558
Closes: https://github.com/opencv/opencv/issues/26309 and https://github.com/opencv/opencv/issues/21078 [for GRU layer]
### 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
Fix IPP warpAffine #28562
The issue is that we compute the inverse transformation and pass that to the HAL, but tell IPP that we use the actual transformation.
https://github.com/opencv/opencv/blob/a269a489b94b84717691533a04f79d9a0e5f479a/modules/imgproc/src/imgwarp.cpp#L2399-L2412
I have added an additional test with `CV_16S` Mats to test the IPP implementation, because right now no other `warpAffine` test enters the IPP branch.
This fixes#28554.
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
This commit addresses a compiler warning encountered when building with GCC 13 and C++20.
The compiler triggers a false-positive -Wstringop-overflow warning in `findKSides`.
By adding `sides.reserve(k)`, we explicitly inform the compiler about the required
memory allocation, which suppresses the warning and provides a minor optimization
by avoiding potential reallocations.
DNN: Fix Squeeze to remove all size-1 dims when axes is empty #28425Fixes#28424
OpenCV Extra: [opencv/opencv_extra#1308](https://github.com/opencv/opencv_extra/pull/1308)
This PR fixes the ONNX Squeeze operator to correctly remove all size-1 dimensions when `axes` is not provided, conforming to the ONNX specification.
### Details
Per [ONNX Squeeze specification](https://onnx.ai/onnx/operators/onnx__Squeeze.html):
> 'If axes is not provided, all the single dimensions will be removed from the shape.'
Previously, OpenCV DNN would not remove any dimensions in this case, causing shape mismatch errors with models like LaMa (inpainting).
### Example
```python
# Input: [1, 1, 2, 4]
# Squeeze with no axes attribute
# Before: [1, 1, 2, 4] ✗ (No change)
# After: [2, 4] ✓ (matches ONNX Runtime)
```
### Tests
Added `testONNXModels("squeeze_no_axes")` which validates this behavior with new test data.
opencv_extra_pr=opencv/opencv_extra#1324
### 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 (4.x for bug fixes)
- [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
docs(calib3d): clarify coordinate systems in projectPoints, undistort Points, and fisheye::undistortPoints #28333
This PR improves documentation clarity by explicitly describing:
- Input/output coordinate systems (pixel vs normalized coordinates)
- When to use normalized vs pixel coordinates in undistortPoints output
- Differences between fisheye and standard pinhole camera models
- Coordinate system transformations for better understanding
Changes:
- projectPoints: Added explicit note about input (world coords) and output (pixel coords)
- undistortPoints: Clarified that input is pixel coordinates, and output depends on parameter P (normalized vs pixel)
- fisheye::undistortPoints: Added comprehensive documentation including coordinate systems, when to use fisheye vs standard model, and distortion coefficient differences
These improvements help users avoid ambiguity when using these functions for camera calibration and 3D vision pipelines.
Fix absdiff with int arguments #28267
I believe the fix to the undefined behavior described in #27080 is simply casting to unsigned before subtraction, because
1. casting int to unsigned is well-defined; negative values get represented modulo $2^{32}$
2. overflow in unsigned subtraction is well-defined and the results are modulo $2^{32}$
Since we are computing everything modulo $2^{32}$ and the result must always be a non-negative number below $2^{32}$, this computation should be well-defined and correct.
I have verified this on ARM Apple Clang and on x64 Linux gcc with `-O3` and both produce the correct values in the reproducer of #27080. The test I have added fails with the integer overflow on both platforms I have tested. Perhaps @fengyuentau could verify if this also fixes the issue on the platforms he has tested?
I have added a fix and removed the workarounds. I recommended this approach in #28229, but he decided to revert it.
### 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
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
Added RoiAlign layer support in new DNN engine #28453
Fixes `Unsupported Operation: RoiAlign` issue in https://github.com/opencv/opencv/issues/20258 and https://github.com/opencv/opencv/issues/22099, model parsing is successful now.
Merge with: https://github.com/opencv/opencv_extra/pull/1310
### 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
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
- Change 'element' to 'kernel' in LaTeX formulas to match actual parameter name
- Fix erode() and dilate() function documentation (lines 2330, 2338, 2362, 2370)
- Fix MorphTypes enum documentation (MORPH_OPEN, MORPH_CLOSE, MORPH_GRADIENT, MORPH_TOPHAT, MORPH_BLACKHAT)
- Fix backtick formatting in dilate() documentation
Resolves#18095
optimize(dnn): optimize Slice layer for strided inputs #28447
## 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:
1. **Parallelization**: Uses `cv::parallel_for_` to parallelize the outermost dimension of the slice operation.
2. **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.
3. **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:**
| Test Case | Before (ms) | After (ms) | Speedup |
| :--- | :--- | :--- | :--- |
| **Strided Axis 0** `[::2, ...]` | 1.10 | **0.02** | **~55x** |
| **Strided Axis 2** `[..., ::2]` | 1.10 | **0.06** | **~18x** |
| **Contiguous** (Baseline) | 0.10 | 0.10 | 1.0x (Unchanged) |
### 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
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
optimize(dnn): parallelize Resize layer implementation #28442
### optimize(dnn): parallelize Resize layer implementation
This PR addresses the `TODO` in `modules/dnn/src/layers/resize_layer.cpp` regarding the slow implementation of the `Resize` layer when using `opencv_linear` or `nearest` interpolation with specific configurations.
### Changes
- Replaced the serial nested loop (batch x channels) with `cv::parallel_for_`.
- This allows OpenCV to utilize multi-threading for the resizing operation, which was previously single-threaded for these specific paths.
### Performance Results
Benchmark run on 20-thread CPU (AVX2):
| Test Case | Resolution Change | Before (ms) | After (ms) | Speedup |
| :--- | :--- | :--- | :--- | :--- |
| **Upsample Linear** | 64x64 -> 128x128 | 1.47 ms | **0.18 ms** | **~8.1x** |
| **Downsample Nearest** | 128x128 -> 64x64 | 1.55 ms | **0.45 ms** | **~3.4x** |
**Test Configuration:**
- **Upsample**: `[4, 64, 64, 64]` -> `[4, 64, 128, 128]` (Factor: 2.0, Linear)
- **Downsample**: `[4, 128, 128, 128]` -> `[4, 128, 64, 64]` (Factor: 0.5, Nearest)
### 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
- Added `modules/dnn/perf/perf_resize.cpp` to verify performance gains.
- [ ] The feature is well documented and sample code can be built with the project CMake
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