predictOptimalVectorWidth() built its vectorWidths table with 8 entries
(depths CV_8U..CV_16F), but checkOptimalVectorWidth() indexes it by depth.
The 5.x depths CV_16BF, CV_Bool, CV_64U, CV_64S and CV_32U therefore read
past the end of the array; the garbage value can slip past the ckercn <= 0
guard, and the divider normalization loop then shifts the divider to zero,
so "offsets[i] % dividers[i]" raises SIGFPE. The failure is allocation
dependent and shows up as a sequence-dependent crash, e.g. in the OpenCL
Norm tests for CV_32U (cv::norm on a UMat reaches this via ocl_sum, which
calls predictOptimalVectorWidth before its own depth guard bails out).
Size the table to CV_DEPTH_MAX so every depth is in bounds and map the new
fixed-size integer depths to their natural OpenCL vector widths; CV_16BF
has no OpenCL vector type and stays scalar. Add a regression test covering
all depths.
- Replace the fixed-128-bit per-depth minMaxIdx kernels with a single templated universal-intrinsic core
- added simd dispatch AVX-512 dispatch
- A dual-accumulator inner loop added
Uses universal intrinsics, so all SIMD backends benefit.
Follow-up to the recent "reject under-length raw exif profile" change.
The declared length in a PNG raw exif profile (tEXt/zTXt "Raw profile type
exif" chunk) is fully attacker controlled. The < 6 guard stops the underflow,
but a large positive value still passes it and reaches HexStringToBytes(),
which does raw_data.resize(expected_length) before reading anything. So a few
bytes in a text chunk can force a ~2GB allocation -> easy memory-amplification
DoS while decoding an otherwise small PNG.
The payload is hex encoded (two characters per byte), so a valid length can
never exceed the profile text carrying it. Reject any declared length greater
than profile_len. This bounds the allocation to the input size and doesn't
reject any valid profile; the valid decode path is unchanged.
imgproc: optimized LUT and equalizeHist with SIMD #29250
- optimized lut with SIMD
- support equalizeHist with v_lut
### 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
Improved color convert and AVX512 dispatch added #28992
### 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
Optimization ArUco: get border errors in one pass for both normal and inverted markers #29329
This PR is a follow up to optimization in https://github.com/opencv/opencv/pull/29267.
## Context:
When detecting inverted markers, we call `_getBorderErrors` twice:
- `int borderErrors = _getBorderErrors(cellPixelRatio, ...);`
- `Mat invCellPixelRatio = 1.f - cellPixelRatio;`
- `int invBError = _getBorderErrors(invCellPixelRatio, ...);`
meaning:
1. Scan border cells once.
2. Allocate a new Mat.
3. Invert the entire `cellPixelRatio` matrix, not just the border.
4. Scan border cells again on the inverted matrix.
5. If inverted marker is better, copy the full inverted matrix back
## Solution
only call `_getBorderErrors` once and compute both
- borderErrors: `cellPixelRatio > validBitIdThreshold`
- invBorderErrors: `1 - cellPixelRatio > validBitIdThreshold`
This saves:
1. full invert into temporary Mat: (`Mat invCellPixelRatio = 1.f - cellPixelRatio;`)
2. scan temporary border: the second `_getBorderErrors`
3. copy temporary Mat back into `cellPixelRatio`: `invCellPixelRatio.copyTo(cellPixelRatio);`
Note that the solution does not implement:
```
if(params.detectInvertedMarker) {
_getBorderErrorsBoth(...);
} else {
borderErrors = _getBorderErrors(...);
}
```
because the extra cost to computing invBorderErrors: `if(1.f - ratio > validBitIdThreshold) invBorderErrors++;` is negligible. this also avoids having to maintain two functions: `_getBorderErrorsBoth` and `_getBorderErrors`
## Tests:
No visible results when testing the full marker detection pipeline because this step is not expensive. There is a roughly 8% noise when re-running the marker detections making it hard to spot small speed diffs.
When testing only this specific step with a float matrix of size: `(markerSize + 2*border)^2` on a AMD Ryzen 7 (8 cores / 16 threads):
- The new code is 30-45× faster at this stage depending on the marker size and whether the candidate was actually an inverted one, saving ~530-580 ns per candidate, mainly because we removed `Mat invCellPixelRatio = 1.f - cellPixelRatio`
- The new code is equivalent when detecting non-inverted markers +/- 3 ns
---
### 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
Restricting the condition with _M_IX86/_M_X64 so it only applies to x86/x64 MSVC builds. MSVC ARM64 now falls through to the existing `#else` branch, which already has a portable CV_SIMD-based exp32f/exp64f implementation
**Performance Benchmarks:**
<img width="976" height="486" alt="image" src="https://github.com/user-attachments/assets/62daf2c3-34ac-4fc7-92d0-268073f746f3" />
- [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 ONNXRuntime dll path mismatch #29309
**1. C2664 build error in `net_impl_backend.cpp`**
`EnableProfiling()` expects `const wchar_t*` on Windows (`ORTCHAR_T`), but was passed `const char*`.
Fixed by converting to `std::wstring`, as suggested in #29278
---
**2. Wrong ORT DLL loaded at runtime (`modules/dnn/CMakeLists.txt`)**
With `DOWNLOAD_ONNXRUNTIME=ON`, the DLL glob only searched `bin/` but the downloaded package places DLLs in `lib/`. This left the build tree with no ORT DLL, causing Windows to fall back to the stale `System32\onnxruntime.dll` (1.17.1), crashing against the ORT 1.25.1 API.
Fixed by adding `lib/` as fallback and staging DLLs into the build bin directory at configure time.
Closes : #29278
### 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
More use of AutoBuffer #28907
When possible, AutoBuffer should be faster than std::vector<>, and should not be worse if it requires a heap allocation rather than a stack allocation.
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
dnn: fix new-engine block layout for RVV when VLEN > 128 #29304
### 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
<!-- Note!!! If you are an automated agent, we have a special process for you: add 🤖🤖🤖 to the end of the PR title. -->
#### Problem
Fixes#28852. The new DNN engine packs activations in a blocked NCHWc layout with a fixed channel-block size `C0 = 8`. The blocked-layout kernels (MaxPool, AveragePool, BatchNorm, depthwise Conv, ConvTranspose, generic Conv) load one block into a SIMD vector and assert: `C0 == nlanes || C0 == nlanes*2 || C0 % (nlanes*4) == 0`
On RISC-V the universal intrinsics are **scalable with LMUL=2**, so `nlanes = (VLEN/32)*2` — **16 at VLEN=256, 64 at VLEN=1024** — which exceeds the fixed `C0=8`. The assertion fails with `-215` and the ONNX pooling/conv conformance tests abort. #29180 worked around it by disabling the RVV SIMD path in those kernels.
#### Fix
Make the block size track the hardware vector width on RVV instead of assuming 8:
- `net_impl.cpp`: `defaultC0 = max(8, VTraits<v_float32>::vlanes())` (16/64 on RVV).
- The fp32 blocked kernels read `C0` at runtime and size scratch buffers by `max_nlanes` (bounded by the compile-time `CV_RVV_MAX_VLEN`, default 1024).
- All changes are guarded by `CV_SIMD_SCALABLE`, so **x86/NEON are unchanged**.
- The int8 quantized kernels are hardwired to `C0=8` (VNNI/NEON packing + per-channel quant) and are scalar on RVV, so quantized graphs are pinned to `C0=8` in `prepareForInference()` (detected via a `CV_8S` arg); only fp32 graphs use the wider block.
#### Validation (native RISC-V)
I have already conducted tests on the Spacemit K3, covering both the X100 (VLEN=256) and the A100 (VLEN=1024).
`opencv_test_dnn`, ENGINE_AUTO (new engine), no assertions:
| VLEN | Test_ONNX_conformance | Test_ONNX_layers (conv/pool/depthwise/quantized/MobileNet_v4) |
|------|-----------------------|--------------------------------------------------------------|
| 256 | 1641 / 1641 | all pass (incl. `Quantized_Convolution`) |
| 1024 | 1641 / 1641 | all pass (incl. `Quantized_Convolution`) |
Reject initializers whose declared shape claims more elements than the tensor payload (raw_data or a typed *_data field) actually holds, before the Mat copy/convert reads them.
Fix remap nearest rounding #29145
Thanks, I checked the Windows x64 test logs. The imgproc failures are from the OpenCL `Remap_INTER_NEAREST` tests with `(16SC2, 16UC1)` maps. I missed the OpenCL fixed-point path in the first patch.
I updated `modules/imgproc/src/opencl/remap.cl` to use the same nearest rounding condition as the CPU path. This should address the OCL remap failures.
The `opencv_test_video` failure seems unrelated to this PR (`ECCfixtures/Video_ECC.accuracy/6` invalid memory access), since this PR only touches remap rounding in imgproc.
### 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
Added harfbuzz; use it instead of STB to render text #29300
Merge with https://github.com/opencv/opencv_extra/pull/1378.
This is the next big step to improve font rendering in OpenCV 5.x. See #18760, #26301. See also OpenCV 5.0 release notes, where it was pointed out that complex scripts are not rendered correctly, and HarfBuzz integration is needed to fix it. So, here it is — HarfBuzz integration:
* Removed tweaked STB engine. STB truetype rendering engine was included into OpenCV 5.0-pre/5.0 and it was extended to instantiate and render variable fonts, but the support was incomplete and immature.
* Instead, we now use [HarfBuzz](https://github.com/harfbuzz/harfbuzz) — famous font shaping library and now also font rendering library, used by many big companies and organizations.
* As a result, we now correctly render complex scripts, such as arabic or devanagari, correctly handle font ligatures (ff, fi, ft etc.)
<img width="1300" height="600" alt="text_test" src="https://github.com/user-attachments/assets/a7d2c754-0fcf-40f8-8104-578f3a14850b" />
* Potentially, we could also support color emoji, but that would be a next step.
* As with STB-based engine, glyphs are cached (the same glyph from the same font is not rendered twice), so the performance should be on par with the previous engine.
* When OpenCV is built with `-DWITH_HARFBUZZ=ON`, which is set by default, it tries to detect HarfBuzz in the system and use it. If it's not detected, OpenCV builds our own small subset of HarfBuzz.
The following table compares size of libopencv_imgproc.dylib.5.0.0 (Release mode) in different configurations:
| Configuration | libopencv_imgproc (stripped) | delta vs 5.0 |
|----------------------------------------|------------------------------|----------|
| imgproc without text rendering (`-DWITH_HARFBUZZ=OFF`) | 4.27 MB | −2.35 MB |
| imgproc with stb-based engine (5.0) | 6.62 MB | 0.0 Mb |
| imgproc with HarfBuzz-based engine (this PR) | 7.07 MB | +0.45 MB |
The biggest source of the size increase when OpenCV is built with text rendering support (STB- or Harfbuzz-based) is that imgproc in this case includes .ttf fonts (Rubik and 'Wen Quan Yi Micro Hei'), which are gzip-compressed, but still have noticeable size, especially 'Wen Quan Yi' (~2Mb). HarfBuzz itself, compared to STB engine, adds just 0.45Mb, or ~7% to imgproc size. On other platforms (Linux x64, Windows), where IPP or other acceleration libraries are linked into libopencv_imgproc, the harfbuzz footprint is even less noticeable.
### 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(pam): fix out-of-bounds write when reading 2-channel PAM #29296
While poking at the PAM decoder I noticed basic_conversion() writes past the
end of the destination buffer when a GRAYSCALE_ALPHA (2 channel) image is read
with IMREAD_GRAYSCALE.
The 1-channel branch was written as if the destination had 3 channels:
for( ; s < end; d += 3, s += src_sampe_size )
d[0] = d[1] = d[2] = s[layout->graychan];
So for every source pixel it writes 3 bytes and advances d by 3, even though
the output row only has m_width bytes (1 channel). With m_channels == 2 that
ends up writing ~1.5 * m_width bytes per row, which runs off the row and, on
the last row, off the end of the Mat. m_width is taken straight from the file
header (up to 2^20), so the overflow size and contents are attacker controlled.
It's reachable with a plain imread(file, IMREAD_GRAYSCALE) on a crafted file.
While looking at it I also realised the loop bound was off for any multi
channel source: end was set to src + src_width, but the source has
src_width * channels samples, so it only ever processed m_width/channels pixels
instead of all of them. That's why GRAYSCALE_ALPHA / RGB_ALPHA come out only
partially filled.
Fix both at once:
- end now covers the whole row (src_width * src_sampe_size)
- the 1-channel branch writes one byte and advances d by 1
For the common grayscale->color case (channels == 1) the new end is identical
to the old one (m_width * 1 == m_width), so that path is byte for byte the same
and the existing PAM read_write test is unaffected. The only outputs that
change are the GRAYSCALE_ALPHA/RGB_ALPHA conversions, which were already broken.
Added a regression test (Imgcodecs_Pam.decode_graya_as_gray) that builds a small
2-channel PAM with an odd width, decodes it as grayscale and checks the result
matches the gray channel. It overflows/crashes on the old code and passes now.
objc: Fix VolumeType enum name clash on MacOS #29262
### 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
- [ ] The feature is well documented and sample code can be built with the project CMake
**Problem**
When the ObjC wrapper is generated, the global enum `cv::VolumeType` from the ptcloud module is emitted as `typedef NS_ENUM(int, VolumeType)`. macOS defines `typedef OSType VolumeType` in CoreServices, which leads to a typedef-redefinition error during the framework build.
**Fix**
`add_enum()` in `gen_objc.py` now handles namespace-global enums by falling back to a module-level lookup (`self.Module`) when the enum has no enclosing class. A new `gen_dict.json` entry maps `VolumeType` -> `PtcloudVolumeType`, and the import generation automatically uses the renamed enum.
Fixes#29260
doc: remove duplicated bib #29298
### 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
When computing TM_SQDIFF for 8-bit images, crossCorr stores intermediate
results in CV_32F which loses precision for large patch sums (e.g. 25x25
patch of value 255 gives sum=40603125, exceeding float32's ~7 significant
digits). This causes the final SQDIFF result to have incorrect non-zero
values even when image and template are identical.
Fix: use a CV_64F intermediate buffer for crossCorr and common_matchTemplate
when depth==CV_8U and method is TM_SQDIFF or TM_SQDIFF_NORMED, then convert
back to CV_32F for the final output.
Fixes#21786
Improving Parallelism and Memory Access Efficiency for Hough Transform Accumulator #29059
### 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
# [Optimization] Improving Parallelism and Memory Access Efficiency for Hough Transform Accumulator
## Overview / Motivation
The original implementation mainly rely on single‑threaded nested loops, which do not fully utilize the computational power of modern multi‑core CPUs. There is also room for improvement in memory access patterns and branch prediction. **Without altering any core mathematical logic or ensuring result consistency**, this work improves the execution efficiency of these two processes by introducing `cv::parallel_for_` and refactoring data access patterns.
---
## Detailed Changes
* **Original Code Analysis**: The original code uses a double loop – the outer loop scans the image for edge points (`if image[...] != 0`), and the inner loop iterates over all angles, computes the radius, and writes to the global `accum` array. This pattern is hard to parallelize directly because different threads writing to the same accumulator would cause **data races**. Moreover, the sparse conditional branch inside the loop is extremely unfriendly to CPU branch prediction.
* **Optimization Strategy (Sparse Extraction → Parallel over Angles)**:
1. **Sparse Feature Extraction**: First, pre‑scan the image in a single thread, extract the coordinates (`x`, `y`) and values of all non‑zero pixels (edge points) into a contiguous `std::vector` (pre‑allocate 10% of the image size to reduce dynamic reallocation overhead).
2. **Switch the Parallel Dimension**: Instead of splitting the image region, change the parallelization dimension to **angle (`numangle`)**. Use `cv::parallel_for_` to assign different angle ranges to different threads.
3. **Conflict‑free Memory Writes**: Because the `accum` array is strictly partitioned by angle `n` in memory, threads assigned to different angles write to completely non‑overlapping memory blocks in the global `accum`.
---
## Correctness Testing
Correctness tests are based on the provided `opencv_test`. For the Hough tests, no failing test cases were observed.
---
## Performance Benchmarks
> The following tests were run on Intel(R) Core(TM) i9‑14900HX @ 2.2GHz / Windows 11 (WSL: Ubuntu) with GCC 13.3.0.
Using `opencv_perf` tests that include Hough, the results are as follows:
| Test Case | 1st mean | 5th mean | Diff |
|-----------|----------|----------|------|
| `PerfHoughCircles.Basic` | 4.75 | 4.91 | +3.4% |
| `PerfHoughCircles2.ManySmallCircles` | 56.76 | 59.37 | +4.6% |
| `PerfHoughCircles4f.Basic` | 4.14 | 4.03 | -2.7% |
#### II. `OCL_HoughLines` (Standard Hough Line, OCL wrapper, actually executed on CPU)
| Parameters (size, rho, theta) | 1st mean | 5th mean | Diff |
|-------------------------------|----------|----------|------|
| (640×480, 0.1, 0.01745) | 2.57 | 3.21 | +24.9% |
| (640×480, 1, 0.1) | 0.18 | 0.21 | +16.7% |
| (1920×1080, 0.1, 0.01745)|12.27 |15.55 | +26.7% |
| (1920×1080, 1, 0.1) | 0.69 | 0.99 | +43.5% |
| (3840×2160, 0.1, 0.01745)|28.43 |34.78 | +22.3% |
| (3840×2160, 1, 0.1) | 2.15 | 3.51 | +63.3% |
#### III. `OCL_HoughLinesP` (Probabilistic Hough Line)
| Image and parameters (rho, theta) | 1st mean | 5th mean | Diff |
|------------------------------------|----------|----------|------|
| pic5.png, 0.1, 0.01745 | 1.20 | 1.22 | +1.7% |
| pic5.png, 1, 0.01745 | 1.03 | 0.92 | -10.7% |
| a1.png, 0.1, 0.01745 | 8.71 | 9.32 | +7.0% |
| a1.png, 1, 0.01745 | 6.29 | 6.68 | +6.2% |
#### IV. Standard Hough Line (CPU implementation, non‑OCL) `Image_RhoStep_ThetaStep_Threshold_HoughLines`
| Parameters (image, rho, theta, thresh) | 1st mean | 5th mean | Diff |
|-----------------------------------------|----------|----------|------|
| pic5.png, 1, 0.01, 0.5 | 2.19 | 0.82 | **-62.6%** |
| pic5.png, 10, 0.01, 0.5 | 2.08 | 0.53 | **-74.5%** |
| pic5.png, 1, 0.1, 0.5 | 0.24 | 0.15 | -37.5% |
| a1.png, 1, 0.01, 0.5 | 16.06 | 2.65 | **-83.5%** |
| a1.png, 10, 0.01, 0.5 | 17.05 | 1.92 | **-88.7%** |
| a1.png, 1, 0.1, 0.5 | 1.82 | 1.00 | -45.1% |
#### V. Floating‑Point Hough Line (`...HoughLines3f`)
| Parameters (image, rho, theta, thresh) | 1st mean | 5th mean | Diff |
|-----------------------------------------|----------|----------|------|
| pic5.png, 1, 0.01, 0.5 | 1.97 | 0.86 | **-56.3%** |
| pic5.png, 10, 0.01, 0.5 | 1.66 | 0.54 | **-67.5%** |
| a1.png, 1, 0.01, 0.5 | 18.52 | 2.59 | **-86.0%** |
| a1.png, 10, 0.01, 0.5 | 16.30 | 2.05 | **-87.4%** |
| a1.png, 1, 0.1, 0.5 | 1.72 | 0.97 | -43.6% |
### Conclusion
- **Circle detection, probabilistic Hough line**: Differences between the two runs are very small (within ±11%), indicating stable performance.
- **`OCL_HoughLines`**: The parallel test is generally 10%~63% slower than the serial one, but still within a reasonable fluctuation range. Special handling was attempted but did not bring significant improvement and slightly reduced the gains in the subsequent two groups, so it was left unchanged after comprehensive consideration.
- **CPU standard Hough line (non‑OCL)**: The parallel test is significantly faster than the serial one (up to 88% faster), demonstrating that parallel optimization can bring obvious improvements.
By the way at last, I am extremely grateful to the maintainers for helping me test the last PR. However, since I was unable to obtain the development board, I was unable to continue modifying the previous RVV optimization.
Fix speed regression in Aruco identify #29267
### 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
core(opengl): fix memory leak in OpenCL extensions gathering #28981
## Problem
Fixes#28980
In `modules/core/src/opengl.cpp`, inside `initializeContextFromGL()`, a `char[]` buffer is allocated to query OpenCL device extensions:
```cpp
extensions = new char[extensionSize];
status = clGetDeviceInfo(..., extensions, &extensionSize);
if (status != CL_SUCCESS)
continue; // leaks `extensions`
```
When `clGetDeviceInfo()` fails, `continue` skips the corresponding `delete[]` on the success path, causing the allocated buffer to leak.
Additionally, the `catch (...)` block also bypasses cleanup, so any thrown exception leaks the buffer as well.
## Fix
Replace the raw `char*` allocation with `std::unique_ptr<char[]>`.
This ensures the buffer is automatically released on all exit paths, including:
- normal execution
- early `continue`
- exception handling paths
## Checklist
- [x] I agree to contribute to the project under the Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on code under GPL or another license 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, if applicable.
- [x] Accuracy/performance tests and test data in `opencv_extra` are included, if applicable.
- [x] The feature/change is documented and sample code can be built with the project CMake configuration, if applicable.
imgproc: optimize EMD (Earth Mover's Distance) solver performance #29194
### imgproc: optimize EMD solver performance using O(V) spanning tree traversal
---
This PR significantly optimizes the performance of the Earth Mover's Distance (`cv::EMD`) solver in `modules/imgproc/src/emd_new.cpp`.
Specifically, it refactors the dual-variable calculation in `EMDSolver::findBasicVars()` from a naive $O((N+M)^2)$ linked-list scanning approach to an optimized $O(N+M)$ BFS tree traversal utilizing existing adjacency lists, leading to a massive speedup.
---
#### Technical Details & Core Bottleneck Fixed
1. **Algorithmic Complexity Reduction in `findBasicVars()`:**
- **Before**: The original implementation solved the dual variables $u_i$ and $v_j$ by traversing the entire unmarked rows (`u0_head`) or columns (`v0_head`) linked-lists and invoking `getIsX(i, j)` inside nested loops to find connected basic variables. This resulted in an $O((N+M)^2)$ complexity per simplex iteration. For a scale of $2000 \times 2000$, this performed up to $16,000,000$ operations per iteration.
- **After**: Since `EMDSolver` already maintains the adjacency lists of the basic variables tree (`rows_x` and `cols_x`), we can traverse the spanning tree in linear time. This PR implements a dual-queue BFS tree traversal. The complexity per iteration is drastically reduced to $O(N+M)$, performing at most $4000$ operations per iteration.
2. **Cache Locality & Pointer-Chasing Elimination:**
- Replaced pointer-chasing on dynamically-allocated linked lists with contiguous, stack-allocated array queues (`cv::AutoBuffer`), significantly improving CPU L1/L2 cache hit rates and enabling hardware prefetching.
---
#### Performance Benchmarks
Below is the benchmark comparison evaluated on a standard CPU.
#### Test 1: dims = 64
| Scale ($N, M$) | Original EMD (ms) | Optimized EMD (This PR) | Speedup |
| :--- | :--- | :--- | :--- |
| **100** | 5.473 | 3.419 | **1.60x** |
| **500** | 381.871 | 244.355 | **1.56x** |
| **1000** | 1893.053 | 1369.016 | **1.38x** |
| **2000** | 11387.792 | 8331.221 | **1.37x** |
#### Test 2: dims = 3
| Scale ($N, M$) | Original EMD (ms) | Optimized EMD (This PR) | Speedup |
| :--- | :--- | :--- | :--- |
| **100** | 4.433 | 3.042 | **1.46x** |
| **500** | 365.762 | 259.735 | **1.41x** |
| **1000** | 1989.400 | 1421.952 | **1.40x** |
| **2000** | 12731.836 | 7952.210 | **1.60x** |
*(Note: The exact performance figures may vary slightly depending on the compiler and test machine.)*
---
#### Verification
- All existing tests in `opencv_test_imgproc` (including EMD tests) pass successfully. No regressions were introduced.
---
### 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
Jesus Armando Anaya
Agrim Rai
uwezkhan
Alexander Smorkalov
Madan mohan Manokar
arshsmith
Alexander Smorkalov
Jonas Perolini
Pratham Kumar
Varun Jaiswal
Pierre Chatelier
velonica0
熊阔豪
Vadim Pisarevsky
Stephan T. Lavavej
Andrei Fedorov
Haris shakeel
Kumataro
Vincent Rabaud
Rishiii57
ZNNAXLRQ
Yixuan Tang
Srujan rai
Ding zhehao