Add ARMPL support for DFT Function #28664
- This PR introduces hal/armpl/ with implementation of 1D, 2D DFT and DCT routines using ARM Performance Libraries as a custom HAL replacement for OpenCV's DFT & DCT Function.
- ArmPL MSI package is automatically downloaded and extracted via CMake when building on Windows ARM64, with a WITH_ARMPL option that defaults to ON for that platform.
- Forward and inverse real DFT calls in dxt.cpp are routed through ArmPL when available, with scaling applied only when needed.
- Test error thresholds in test_dxt.cpp are relaxed (from 1e-5 to 2e-4 for float ) to account for numerical differences between ArmPL and OpenCV's reference DFT results.
**Performance Benchmarks :**
<img width="993" height="835" alt="image" src="https://github.com/user-attachments/assets/76def647-6d20-4bce-8bc9-7363e723669f" />
- [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
fix: Guard ndsrvp filter center copy when source span is empty #28915
## Summary
This adds a defensive guard around the centre-region `memcpy` in the ndsrvp HAL filter padding path.
**Description**: Multiple memcpy calls in the ndsrvp HAL filter, bilateral filter, and median blur routines use computed sizes (e.g., cnes * (rborder - j), cn * (rborder - j), src_step * height) without validating that the computed byte count fits within the destination buffer. An attacker supplying a crafted image with manipulated dimensions, channel counts, or border parameters can cause the computed copy size to exceed the allocated destination buffer, resulting in a heap buffer overflow that corrupts adjacent memory.
## Changes
- `hal/ndsrvp/src/filter.cpp`
## Verification
- [x] Build passes
- [x] Scanner re-scan confirms fix
- [x] LLM code review passed
---
*Automated security fix by [OrbisAI Security](https://orbisappsec.com)*
cmake: fix PNG status display when BUILD_PNG=ON #28995
### Description
Fixes#28657.
On macOS (and other Apple platforms), `BUILD_PNG=ON` is the default. The build system correctly clears `PNG_FOUND` in `OpenCVFindLibsGrfmt.cmake` and builds libpng from the bundled source. However, during the subsequent module processing phase, a downstream `find_package(PNG)` call — triggered transitively via `include()` in the **same scope** — overwrites not only `PNG_FOUND`, but also `PNG_INCLUDE_DIR`, `PNG_LIBRARIES`, and `PNG_VERSION_STRING`.
#### Root Cause: FindPNG.cmake Has Asymmetric Guards
Reading CMake 4.3's `FindPNG.cmake` (`/opt/homebrew/share/cmake/Modules/FindPNG.cmake`) reveals:
| Variable | Guard? | Fate |
|---|---|---|
| `PNG_LIBRARY` | `if(NOT PNG_LIBRARY)` at line 138 — **guarded** | Preserved |
| `PNG_PNG_INCLUDE_DIR` | `find_path(...)` at line 115 — **no guard** | **Overwritten** |
| `PNG_INCLUDE_DIR` | Derived from `PNG_PNG_INCLUDE_DIR` | **Chain-overwritten** |
| `PNG_LIBRARIES` | Derived from `PNG_LIBRARY` + `ZLIB_LIBRARY` | **Partly overwritten** |
| `PNG_VERSION_STRING` | Parsed from `PNG_PNG_INCLUDE_DIR/png.h` | **Overwritten** |
`PNG_LIBRARY` survives because FindPNG itself checks `if(NOT PNG_LIBRARY)`. But `find_path(PNG_PNG_INCLUDE_DIR)` runs unconditionally — re-searching and overwriting the bundled path with the system one.
#### Fix: Three Coordinated Changes
**Part A — Status guard** (`CMakeLists.txt`): When `BUILD_PNG=ON`, pass `FALSE` as the condition to always show `"build"` regardless of `PNG_FOUND`.
**Part B — Variable lock** (`cmake/OpenCVFindLibsGrfmt.cmake`): After building from bundled source, lock `PNG_PNG_INCLUDE_DIR` as `CACHE INTERNAL`. CMake's `find_path()` checks the cache first — if the variable exists with a valid path, it skips re-searching. The system path is never found.
**Part C — Cache cleanup** (`cmake/OpenCVFindLibsGrfmt.cmake`): Add `PNG_PNG_INCLUDE_DIR` to the `ocv_clear_internal_cache_vars()` call in the `else` branch. When a user switches `BUILD_PNG=OFF`, the cached variable is cleared, allowing `find_path` to search for the system libpng normally. Prevents stale cache leakage across configuration changes.
#### Verification (macOS 26, CMake 4.3, Homebrew libpng 1.6.58)
```
BEFORE downstream find_package(PNG):
PNG_LIBRARY = libpng
PNG_INCLUDE_DIR = .../3rdparty/libpng
PNG_VERSION_STRING = 1.6.37
AFTER downstream find_package(PNG) [with fix]:
PNG_LIBRARY = libpng ← preserved (FindPNG guard)
PNG_INCLUDE_DIR starts with .../3rdparty/libpng ← locked (Part B)
PNG_VERSION_STRING = 1.6.53 ← from bundled png.h
Status display: build (ver 1.6.53) ← correct (Part A)
```
The full reproduction and analysis are in the attached `bugReview/` directory.
### Checklist
- [x] There is a reference to the original bug report and related work
- [x] The test case is in `bugReview/` directory
- [x] Tested on macOS 26 (arm64) with CMake 4.3 + Homebrew libpng 1.6.58
- [x] Cache hygiene verified for BUILD_PNG ON→OFF→ON transitions
flann: fix Index::radiusSearch output size mismatch #28990
## Problem
`Index::radiusSearch` returns `nn` — the number of neighbors found within the radius — but the output arrays `_indices` and `_dists` are always allocated with `maxResults` columns regardless of how many neighbors were actually found. This creates two inconsistencies:
1. When `nn < maxResults`, the output arrays contain stale entries beyond position `nn`, so `nn != indices.cols` and callers cannot rely on the output size to know how many results are valid.
2. When `nn > maxResults`, the return value exceeds the capacity of the output arrays, which have only `maxResults` columns. The extra neighbors were never stored, so the return value is misleading.
The following snippet reproduces both cases:
```cpp
int testFLANN(){
std::vector<cv::Point2f> corners={{3679.83,1857.22},{3324.43,1850.67},{3278.83,1502.32},{3621.32,1508.69},{3662.26,1837.97},{3336.06,1839.28},{3291.74,1516.03},{3608.94,1518.72},{2980.66,1843.22},{2628.11,1837.14},{2607.73,1491.57},{2948.22,1496.76},{2289.31,1830.19},{1943.99,1824.17},{1945.51,1482.34},{2280.68,1487.39},{1607.47,1819.11},{1260.04,1813.26},{1283.94,1470.34},{1620.03,1475.85},{923.063,1808.08},{576.193,1802.4},{624.713,1459.78},{959.715,1464.93},{3270.25,1494.98},{2952.95,1492.19},{2922.75,1190.02},{3231.05,1194.81},{3284.82,1507.62},{2942.74,1502.59},{2912.32,1178.33},{3242.98,1183.19},{2612.82,1496.37},{2276.44,1491.63},{2267.61,1170.13},{2593.64,1174.43},{1949.73,1486.61},{1614.92,1480.64},{1626.77,1160.34},{1952,1165.51},{1289.38,1476.21},{953.709,1470.21},{986.779,1148.92},{1311.98,1154.89},{3567.28,1195.1},{3237.51,1189.03},{3197.63,884.15},{3518.61,888.76},{2918.31,1183.62},{2588.69,1179.37},{2570.64,875.672},{2889.87,878.902},{2271.97,1174.25},{1947.62,1169.61},{1948.56,868.197},{2263.8,872.533},{1630.99,1164.6},{1306.74,1159.52},{1327.81,858.358},{1642.69,862.765},{992.896,1155.52},{666.107,1149.96},{705.246,845.776},{1023.25,851.582},{3204.48,889.981},{2883.49,885.252},{2859.31,593.752},{3175.43,594.736},{2575.86,880.331},{2259.44,876.647},{2252.33,589.235},{2560.47,592.332},{1954.36,873.708},{1636.7,868.068},{1646.93,580.76},{1956.14,584.797},{1332.02,862.624},{1017.11,856.71},{1045.32,572.178},{1350.95,577.635},{3481.36,605.324},{3169.05,601.083},{3138.84,324.116},{3446.12,325.545},{2866.14,599.61},{2555.38,597.142},{2541.51,320.931},{2845.5,322.419},{2256.79,593.253},{1950.17,590.12},{1951.8,317.445},{2250.88,319.418},{1654.16,587.663},{1344.83,582.787},{1362.8,309.253},{1663.89,313.056},{1050.94,577.867},{741.476,571.648},{776.433,300.444},{1076.97,304.56},{3327.05,1847.65},{2977.74,1840.48},{2945.48,1499.68},{3281.82,1504.97},{2630.85,1834.22},{2287.2,1828.06},{2278.56,1489.51},{2610.64,1494.31},{1946.11,1822.05},{1604.75,1816.18},{1617.11,1478.59},{1947.62,1484.48},{1262.96,1810.53},{920.46,1805.05},{956.712,1467.57},{1286.66,1473.27},{3618.7,1511.71},{3281.82,1504.97},{3240.24,1186.11},{3564.22,1192.53},{2945.48,1499.68},{2610.64,1494.31},{2591.52,1176.55},{2915.32,1180.97},{2278.56,1489.51},{1947.62,1484.48},{1949.81,1167.56},{2269.79,1172.18},{1617.11,1478.59},{1286.66,1473.27},{1308.98,1157.53},{1628.88,1162.47},{956.712,1467.57},{627.315,1462.81},{669.943,1146.75},{989.494,1151.86},{3240.25,1186.11},{2915.32,1180.98},{2887.03,881.727},{3200.69,886.725},{2591.52,1176.55},{2269.79,1172.19},{2261.62,874.587},{2573.63,878.324},{1949.81,1167.55},{1628.88,1162.47},{1640.44,864.751},{1950.74,870.259},{1308.98,1157.53},{989.494,1151.86},{1019.41,854.787},{1329.92,860.49},{3515.88,891.68},{3200.69,886.725},{3171.89,598.263},{3478.26,602.785},{2887.04,881.725},{2573.63,878.324},{2558.28,594.392},{2863.1,597.005},{2261.62,874.587},{1950.74,870.259},{1952.4,588.114},{2254.56,591.241},{1640.44,864.751},{1329.92,860.49},{1348.65,579.559},{1650.55,584.209},{1019.41,854.787},{708.649,849.44},{745.388,568.534},{1047.42,574.313},{3171.89,598.263},{2863.1,597.005},{2842.6,325.169},{3141.93,326.654},{2558.28,594.392},{2254.56,591.241},{2248.65,321.425},{2544.55,323.537},{1952.4,588.113},{1650.55,584.209},{1660.07,316.284},{1954.02,319.457},{1348.65,579.559},{1047.43,574.312},{1073.06,307.674},{1366.42,312.707}};
cv::flann::KDTreeIndexParams indexParams(1);
cv::Mat data = cv::Mat(corners).reshape(1, static_cast<int>(corners.size()));
auto index = std::make_shared<cv::flann::Index>(data, indexParams);
int maxResults = 4;
int nTimesError1 = 0; // nn != indices.size()
int nTimesError2 = 0; // nn > maxResults
for (size_t i = 0; i < corners.size(); i++) {
std::vector<int> indices(4);
std::vector<float> dists(4);
int nn = index->radiusSearch(data.row(static_cast<int>(i)), indices, dists, 100, maxResults);
if (nn != (int)indices.size()) { nTimesError1++; }
if (nn > maxResults) { nTimesError2++; }
}
std::cout << "nTimesError1: " << nTimesError1 << std::endl; // > 0 before fix
std::cout << "nTimesError2: " << nTimesError2 << std::endl; // > 0 before fix
return 1;
}
```
## Fix
- Capture the search result in `rsearch_ret` instead of returning early from each `switch` case (this also required adding the missing `break` statements that would otherwise have caused fall-through between type-incompatible distance specialisations).
- Cap `rsearch_ret` at `maxResults` so the return value never exceeds the capacity of the output arrays.
- When `rsearch_ret < maxResults`, trim `_indices` and `_dists` to `query.rows × rsearch_ret` via `colRange(0, rsearch_ret).copyTo(...)` so the output dimensions always match the returned count.
core : add NEON intrinsics support for norm_mask function #28610
- This PR adds NEON intrinsics-based implementations for masked norm operations in norm.simd.hpp for ARM64 architecture.
- The optimized implementation uses ARM NEON intrinsics to accelerate masked norm computations (Infinity norm, L1 norm, and L2 norm) used by the norm function when a mask is provided.
- In the x64 architecture, masked norm operations benefit from IPP-based optimized implementations. However, on ARM64, the execution falls back to scalar implementations, which results in lower performance.
- To achieve performance parity with x64, NEON-based SIMD implementations have been added for ARM64.
- Additionally, scalar loop unrolling optimizations have been added for non-masked norm operations.
- After introducing these changes, masked norm operations showed significant performance improvements on ARM64 platforms, particularly for single-channel (cn=1) operations where NEON intrinsics provide the greatest benefit.
<img width="952" height="822" alt="image" src="https://github.com/user-attachments/assets/12d35f93-a316-4520-9d9c-12ce6b371ddb" />
- [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
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
Fix Clp library detection for vcpkg on Windows #28423
## Problem
Building OpenCV with `WITH_CLP=ON` on Windows (vcpkg) fails:
LINK : fatal error LNK1181: cannot open input file 'libClp.lib'
vcpkg generates `Clp.lib` and `CoinUtils.lib`, but OpenCV expected `libClp.lib`/`libCoinUtils.lib`.
## Solution
Modernize CLP detection with a robust, platform-aware approach:
1. **CMake `find_package(Clp CONFIG)`**: detects vcpkg and uses imported targets (`Coin::Clp`, `Coin::CoinUtils`)
2. **Fallback**: pkg-config on Unix/Linux
3. **Skip** Android/iOS
## Benefits
✅ Fixes Windows build with vcpkg
✅ Uses modern CMake targets
✅ Backward compatible with Unix/Linux
✅ Safe for CI and mobile builds
✅ Graceful fallback if CLP unavailable
## Testing
- **Windows 11 + vcpkg**: build succeeds
- **No CLP installed**: configure/build succeeds
- **Linux/Unix**: existing workflows unaffected
- **Android/iOS**: properly skipped
## Changes
- Update `cmake/OpenCVFindLibsPerf.cmake`
- Replace hardcoded library names with CMake targets
- Add mobile platform guards
- Preserve backward compatibility
Fixes#26592
---
### 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 (`4.x`)
- [x] There is a reference to the original bug report and related work (#26592)
- [x] The feature is well documented and sample code can be built with the project CMake
- [x] No additional tests required - this is a build system fix that maintains existing functionality
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.
Zlib upgrade 1.3.2 #28779
### 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
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>
Pratham Kumar
orbisai0security
donotsleepy
Alexander Smorkalov
Rafael Muñoz Salinas
Teddy-Yangjiale
Dmitry Kurtaev
Kumataro
Alexander Smorkalov
Vincent Rabaud
Alex Wu
Anand Mahesh
Maksim Shabunin
Samaresh Kumar Singh
Pierre Chatelier
ekharkov
Ismail
kirilllapi
Chevi koren
Michael Klatis
Alex
Mulham Fetna