hal/riscv-rvv: implement laplacian #28887
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1353
An implementation of laplacian for riscv-rvv hal
Added benchmark in perf_laplacian.cpp
The performance is evaluated on K1 by running
./opencv_perf_imgproc --gtest_filter="Perf_Laplacian*"
Results are attached in the figure below.
CV_8U fast path supports ksize=3 with BORDER_CONSTANT/BORDER_REPLICATE; unsupported combinations fall back to default implementation. See performance results bellow.
### 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
Feat: Add OpenCL support for AKAZE features #28879
Implement OpenCL-accelerated AKAZE feature
detection and descriptor extraction
Benchmarked on RTX 5060 Ti: 1.2x to 3.31x faster
for image sizes from 640x480 to 3840x2160
- Added 8 OpenCL kernels for feature detection and descriptor extraction
- Refactored compute_kcontrast to use OpenCV magnitude() for consistency
- Added comprehensive tests with >95% accuracy vs CPU baseline
### 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
The minMaxIdx dispatch table in modules/core/src/minmax.cpp stored
seven differently typed functions through C-style casts to a single
MinMaxIdxFunc pointer type, which is undefined behaviour and trips
UBSan's -fsanitize=function for any CV_32F or CV_64F input. This
change switches the typedef and every depth-specific helper to take
void pointers for src, minval and maxval, with the original typed
pointer recovered at function entry. The dispatch table no longer
needs C-style casts and the int pointer punning at the call site
goes away. Fixes#28928.
Better AutoBuffer API #28909
Mimic std::vector<> to help replacing std::vector<T> by cv::AutoBuffer<T> when possible
### 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
videoio(dshow): fix crash in videoInput::start() when pVih is NULL #28914
### Summary
This PR fixes a critical application crash in the DirectShow backend when encountering certain legacy or virtual cameras (e.g., Microsoft's DirectShow "Ball" Sample).
### The Problem
In `modules/videoio/src/cap_dshow.cpp`, the function `videoInput::start()` calls `pConfig->GetConnectedMediaType(&mt)`.
- In some edge cases, this call returns `S_OK`, indicating success.
- However, the associated format block `mt.pbFormat` (which `pVih` points to) can still be `NULL`.
- The current implementation uses `CV_Assert(pVih)`, which triggers a hard crash of the entire application when this occurs.
### The Fix
I have replaced the `CV_Assert(pVih)` with a null-pointer check. If `pVih` is `NULL`, the function now returns `false`. This allows the high-level `cv::VideoCapture` to handle the failure (e.g., by returning `false` from `.open()`) instead of crashing the process.
### Engineering Rationale
- Execution Path Consistency: For devices providing valid format headers, `pVih` remains non-NULL. In these cases, the conditional check is skipped, and the execution path is identical to the original implementation.
- Process Stability: Replacing `CV_Assert` prevents immediate process termination (SIGABRT) when a DirectShow filter provides an invalid or empty format block.
- Error Propagation: Returning `false` in `videoInput::start()` allows the initialization failure to propagate through the call stack. This ensures that `cv::VideoCapture::open()` returns `false`, enabling the caller to detect the issue via the standard API (e.g., `isOpened()`) instead of the process being terminated.
### Evidence
I have manually reproduced this crash using the Microsoft DirectShow Ball Sample filter on Windows. As shown in the attached debugger screenshot:
- `deviceID` is 2 (the virtual camera).
- `hr` is `S_OK`.
- `pVih` is `NULL`.
<img width="773" height="1413" alt="dshow_null_pvih_debug_evidence" src="https://github.com/user-attachments/assets/5bc454b4-4a0b-4703-825d-0d5fd23cba28" />
Fixes#28904
### 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
- Replace unsafe pointer arithmetic and direct buffer modification with std::string methods.
- Update documentation to clarify that the last digit is used as compression level and truncated from the actual filename.
- Add test cases for .gz and .gz0-9
doc: modernize Doxygen comments to support for v1.15.0 #28903
This PR addresses several documentation build failures encountered with modern Doxygen versions, particularly v1.15.0 (shipped with Ubuntu 26.04).
- flann module: Updated license headers from /**** to /*M****. This prevents Doxygen from misinterpreting the license text (specifically the unclosed backticks in ``AS IS'') as documentation blocks, which previously caused "Reached end of file" errors.
- core module: Fixed a typo in operations.hpp where a doubled backtick (``) caused parsing to fail.
- tutorials: Fixed a missing backtick in real_time_pose.markdown (around line 108) and corrected typos in the RobustMatcher class name.
- Links: Resolved explicit link request failures in calib3d.hpp by ensuring proper namespace resolution.
These fixes ensure that the documentation can be generated without errors on the latest toolchains.
### 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
- Emscripten 5.0.1+ changed version macros to uppercase and deprecated lowercase ones.
- Updated CMake to detect the version from both cases.
- Added macro aliases in intrin_wasm.hpp to avoid deprecated warnings and ensure compatibility.
videoio: fix C4576 build error with older ffmpeg versions #28894Fixes#28875
### Description
This PR fixes a build failure (`error C4576`) that occurs when building the `videoio` module with older FFmpeg versions (e.g., 4.4.4) using MSVC under strict C++17 mode.
**Root Cause:**
In older FFmpeg headers, the `AV_TIME_BASE_Q` macro is defined using a C99 compound literal `(AVRational){1, AV_TIME_BASE}`. This syntax is non-standard in C++ and is strictly rejected by MSVC when `/std:c++17` is enabled.
**Solution:**
Replaced the `AV_TIME_BASE_Q` macro with FFmpeg's standard `av_make_q(1, AV_TIME_BASE)` function. This resolves the C4576 compiler error and ensures modern C++ compatibility.
*(Note: `av_make_q` is already smoothly polyfilled in `cap_ffmpeg_impl.hpp` for extremely old FFmpeg versions, making this a highly safe, consistent, and zero-overhead replacement.)*
### 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
Add CAP_PROP_IMAGE_SEQ_START #28844
Resolves https://github.com/opencv/opencv/issues/28843
New CAP_PROP_IMAGE_SEQ_START as an open only property for setting the first frame index when a VideoCap is opening with pattern, squashes test_images TODO.
`CAP_FFMPEG`: forwarded to the image2 demuxers "start_number" option.
`CAP_IMAGES`: Now a WithParams variant so the value reaches open() before probe runs, replaces 0 or 1 auto probe for sequence start.
Property is opt in so default behavior is not affected.
Please note that G_STREAMER is not considered here as I think its out of scope, it already has a "start-index" property and its backend is driven by the pipeline strings rather then these printf patterns.
If an alternative solution is preferred that will not involve a new property or promoting CAP_IMAGES to a "WithParams" variant I don't mind implementing.
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
Bump some calib3d files to C++ #28825
This is just copy/pasting files from 5.x (first commit) and applying some light patch for compilation (second commit).
### 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
Avoid lossy Latin-1 conversions when creating/looking up Qt HighGUI windows and convert C-string entry points to UTF-8 explicitly. This fixes non-ASCII title handling paths that could lead to mismatched window lookup and silent display failures.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
objdetect: clear stale outputs in CharucoDetector::detectDiamonds #28818
## Summary
- clear `diamondCorners`/`diamondIds` outputs at the beginning of `CharucoDetector::detectDiamonds`
- prevent stale detections from previous calls when the current call has fewer than 4 markers or finds no diamonds
- add a regression test that pre-fills outputs, calls `detectDiamonds` with 3 markers, and verifies outputs are empty
Fixes#28783.
## Testing
- built `opencv_test_objdetect` locally
- ran `opencv_test_objdetect --gtest_filter=Charuco.detectDiamondsClearsOutputsWithLessThanFourMarkers`
- result: PASS
Multiscale ECC #28802
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1338
### 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
Previously, OpenCL in-place flip kernels (rows/cols/both) could produce
incorrect results compared to the CPU implementation on strict OpenCL
drivers such as Mesa. The kernels relied on implicit load–load–store–store
(LLSS) ordering when src and dst alias, which is not guaranteed by the
OpenCL memory model and may be reordered.
Some vendor drivers happened to preserve the expected ordering, masking
the issue, but Mesa correctly exposes the undefined behavior.
This change introduces dedicated in-place flip kernels that:
- Explicitly detect in-place execution (src == dst)
- Stage data through local memory tiles
- Enforce correct ordering with work-group barriers
- Avoid global memory read/write aliasing hazards
The non in-place path is unchanged.
With this fix, OpenCL in-place flip produces correct and consistent results
across drivers, matches CPU behavior, and complies with the OpenCL memory
model.
Signed-off-by: jiajia Qian <jiajia.qian@nxp.com>
Avfoundation fractional fps seek fix#28833
Accompanied by PR on [opencv_extra](https://github.com/opencv/opencv_extra/pull/1345)
Fixes https://github.com/opencv/opencv/issues/28831
AVFoundation backend seeking slowly drifts for any video which has a non-integer frame rate.
Narrowing of a float `mAssetTrack.nominalFrameRate` to int32_t means fractional rates are treated as integer when seeking by frame number.
Solution implemented in this branch is to use the tracks native rational frame duration when seeking (and available).
I've also included an AVF only test case which uses a new test file in opencv_extra. This test just compares the video caps expected ms vs actual for a known rate file (23.976).
Could consider extending this test to more then just AVF, as from what I can see there are no fractional rate tests / files.
### 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
imgcodecs(png): support cICP metadata for imreadWithMetadata() #28615
Close https://github.com/opencv/opencv/issues/28606
Related https://github.com/opencv/opencv/pull/27741 (support for imwriteWithMetadata)
### 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
The existing 2-pass cross-check implementation requires both forward and
reverse distance computations on GPU, followed by CPU-side filtering.
This adds a single-pass kernel using int64 atomics to eliminate the
reverse pass. The BruteForceMatch_CrossCheckMatch kernel performs forward
matching and tracks best train->query mappings in one GPU pass, reducing
memory transfers. Falls back to 2-pass approach on devices without
cl_khr_int64_base_atomics extension.
Tested on NVIDIA RTX 5060 Ti: 1.65x-1.97x faster than 2-pass GPU,
3.49x-7.33x faster than CPU at 640x480 to 1920x1080 resolutions.
Allow TIFF compression schemes for 32F#28785
Related to [https://github.com/opencv/opencv/issues/28775](https://github.com/opencv/opencv/issues/28775)
Previously, only 32FC3+SGILOG could be specified for TIFF encoding. But when floats use quantization, compression schemes can be efficient even on 32F data. This PR will allow them.
### 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.
- [X] The feature is well documented and sample code can be built with the project CMake
I just don't know what kind of accuracy/performance tests should be added.
Fixes redundant code in Cloning::illuminationChange() which performed
unnecessary copyTo operations. This satisfies Issue #22056.
Testing: No functional changes made; logic identical to before.
Resolves#22056
core(opencl): fix inplace transpose race by enforcing LLSS ordering via local barrier #28686
The former inplace transpose implementation allowed a reordering of global-memory operations across work-items. Specifically, the intended LLSS (Load–Load–Store–Store) access pattern could be reordered by the GPU into LSLS (Load–Store–Load–Store), causing partially written tiles to be observed by other work-items and producing incorrect output.
This patch introduces a tiled LDS-based algorithm and adds an explicit:
barrier(CLK_LOCAL_MEM_FENCE);
between the load and store phases.
### 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
- [ ] 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
python: fix segfault on 0-channel numpy array input #28747
### 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
N/A: a Python unit test is added in `modules/python/test/test_mat.py`. No external test data required.
- [x] The feature is well documented and sample code can be built with the project CMake
N/A: this is a bug fix, not a new feature. No documentation update needed.
### Problem
Passing a numpy array with shape `(H, W, 0)` (0 channels) to any OpenCV function that accepts a `Mat` argument (e.g. `cv2.resize`, `cv2.warpAffine`, `cv2.blur`) causes a **segfault**.
**Reproducer:**
```python
import cv2
import numpy as np
arr = np.zeros((100, 100, 0), np.uint8)
cv2.resize(arr, (200, 200)) # segfault
```
### Root Cause
In `modules/python/src2/cv2_convert.cpp`, the numpy→Mat conversion checks channel validity only against `CV_CN_MAX` (upper bound):
```cpp
if (channels > CV_CN_MAX) // channels=0 passes this check
```
With `channels=0`, `CV_MAKETYPE(0, 0)` produces `type=-8`, which corrupts the Mat's internal type field and causes undefined behavior downstream.
### Fix
Extend the check to also reject `channels < 1`:
```cpp
if (channels < 1 || channels > CV_CN_MAX)
```
**After fix:**
```
cv2.error: src unable to wrap channels, invalid count (0, must be in [1, 512])
```
### Notes
- This affects all functions that accept a `Mat` input, not just `cv2.resize`
- The same bug exists in the `5.x` branch
- A 0-channel array has no valid OpenCV Mat representation; rejecting it with a clear error is the correct behavior and poses no backward-compatibility risk (the previous behavior was a crash)
Alex Wu
Alexander Smorkalov
Anand Mahesh
Maksim Shabunin
Samaresh Kumar Singh
Pierre Chatelier
Teddy-Yangjiale
Kumataro
Ismail
kirilllapi
Vincent Rabaud
Alexander Smorkalov
Alex
Mulham Fetna
Jeevan Mohan Pawar
kjg0724
4ekmah
jiajia Qian
vrooomy
Andrew Yooeun Chun
Lurie97
LHOOL1109