Refactoring and moving IPP functions to HAL for bilateral_filter in Imgproc - #29409
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1hnH2aGmc3D88HGnvM34xczQbRZUgsKsAHorcB-DpLq4/edit?usp=sharing
### 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
## dnn: extend engine-new layer dtype coverage (control flow, Range, Hardmax, MaxUnpool, CumSum/CumProd, MaxPool, Resize2, normalization, Gemm, MatMul)
ONNX permits these dtypes on these ops, but the engine-new layers refused them at graph-construction time, so :
- valid models either failed to load outright or
- a layer quietly converted to float32 instead (Resize2)
- ran but silently lost precision above float32's 24-bit mantissa.
Companion PR (test data) : [1406](https://github.com/opencv/opencv_extra/pull/1406)
### Support added, per layer
| Layer | Types added | Gate / kernel |
|---|---|---|
| If | Bool, 16U, 16S, 32U, 32S, 64U | Gate only — the condition-reading switch already handled every depth |
| Loop | Bool, 16U, 16S, 32U, 32S, 64U | Gate only — same as If |
| Scan | Bool, 16U, 16S, 32U, 32S, 64U | Gate only — Scan never inspects element values at all |
| Range | 16S | Kernel only — gate was already an unconditional passthrough |
| Hardmax | 64F | Gate only — the `double` kernel has existed since 2024, just unreachable |
| MaxUnpool | 64F | Gate + a genuine `double` instantiation of the value-scatter routine |
| CumSum | 32U, 64U | Gate + two instantiations of the existing running-sum template (wraparound on overflow) |
| CumProd | 32U, 64U | Gate + two instantiations of the existing running-product template |
| MaxPool | 8S, 8U, 64F | Kernel only (gate was already open) — new scalar kernel for the blocked values-only path **and** the separate values+indices path, which had its own float32-only assert |
| Resize2 | 32S (nearest-neighbor only) | Gate + native `int32` gather; bilinear/cubic now reject 32S explicitly instead of silently converting to `float` |
| RMSNorm | 64F | Kernel — `fast_norm.cpp` templated on `T`, genuine `double` accumulator |
| LayerNorm | 64F | Kernel — same shared `fast_norm.cpp` path |
| LayerNorm2 | 64F | Kernel — same shared `fast_norm.cpp` path |
| InstanceNorm | 64F | Kernel — existing SIMD float32 blocked path left untouched, new scalar `double` path added beside it |
| GroupNorm | 64F | Kernel — same treatment as InstanceNorm |
| Gemm | 64F | Kernel — dedicated `cv::gemm` path, bypassing the float-only fastGemm/MLAS kernels |
| MatMul | 64F, 32S, 64S, 32U, 64U | Gate + two new paths: per-batch `cv::gemm` for 64F, and a direct 64-bit-accumulated loop for the four integer types |
Removed `test_maxpool_2d_uint8` from `opencv_all_denylist` : with 8U now supported, the test passes NORMASSERT on all backend/target combinations .
### 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
This PR is about Introducing cuDNN JIT support for the DNN Module
### 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
Added GridSample BiCubic, Dropout support - #29783
Updated ONNX coverage after this PR: 74.8%
### 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
Extend data type support in elementwise, gather and scatter layers - #29786
### PR Changes:
### Support added, per layer
| Layer | Types added | Gate / kernel |
|---|---|---|
| Abs | 8U, 8S, 16U, 16S, 32U, 32S, 64U, 64S | Gate + new templated integer kernel |
| Sign | 8U, 8S, 16U, 16S, 32U, 32S, 64U, 64S | Gate + same templated kernel |
| Neg | 32S | Gate only. The kernel already had a `CV_32S` branch |
| GatherElements | 64F, 16U, 16S, 32U, 64U | Gate + element-width dispatch |
| Scatter | 64F, 16U, 16S, 32U, 64U | Gate + dispatch arms, all five reductions checked |
| ScatterND | 64F, 16U, 16S, 32U, 64U | Gate + dispatch arms, same as Scatter |
| GatherND | 64F, 16U, 16S, 32U, 64U | Gate + element-width dispatch |
| Slice2 | (fix) | Kernel. Wrong-width copy, see below |
`Abs`/`Sign` use one template over all widths with the signed/unsigned split resolved at compile time;
unsigned `abs` short-circuits to `copyTo` and unsigned `sign` reduces to `x != 0`. `GatherElements` and
`GatherND` only move elements, so their per-dtype arms collapsed to four widths. `GatherND` also unified a
target-conditional gate that split `16F`/`32F` by target in a file with no OpenCL path.
`Slice2` had two duplicated depth chains that both fell through to `run_parallel<float>`, a 4-byte copy, so
`64F`/`64U` truncated and `16U`/`16S` read and wrote past the element. Reachable only when the innermost axis
has `step != 1`, which is why the float32 slice tests passed. Now dispatches on `elemSize()`, matching
`pad2_layer.cpp`.
**Two further fixes:** signed-overflow UB in the int64 `Power`/`Neg` path (`sp[i] * scale` is undefined at
`INT64_MIN`, now multiplied through `uint64_t`), and `CV_OCL_RUN` now skips integer depths, since the OCL
activation kernels are float math and `CV_32S` would have gone through a 24-bit mantissa.
**New accuracy tests in `test_int.cpp`**: `Test_Abs_Int`, `Test_Sign_Int`, `Test_Neg_Int`, `Test_Scatter_Int`,
`Test_GatherND_Int`, with `Test_GatherElements_Int` and `Test_ScatterND_Int` widened to nine depths.
Removed `test_slice_start_out_of_bounds` from the parser denylist.
### 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
feat: support boolean (CV_Bool) images in imwrite - #29407
## Summary
`imwrite` failed on `CV_Bool` (boolean) images because no encoder handles that depth. This normalizes a boolean image to `CV_8U` (mapping true to 255) before encoding, so boolean masks can be written directly instead of requiring a manual `convertTo` at every call site.
Adds round-trip tests covering boolean-image encoding.
Fixes#29365
AI was used for assistance.
Imgproc test cleanup - #29740
co-authored by: @Prasadayus
### Re-enabled as-is (stale disable reasons)
- `FillPolyFully.fillpoly_fully` (`test_drawing.cpp:1142`)
- `Resize_Bitexact` (`test_resize_bitexact.cpp:188`, 4 instantiations): `INTER_NEAREST` and
`INTER_NEAREST_EXACT` agree exactly at integer upscale factors; measured 0.0 diff on all 4.
### Add assertions
- **imgproc** — new `Imgproc_Watershed.regression`: `cv::watershed` had no working coverage at all.
### 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
Objdetect test cleanup - #29741
co-authored by: @Prasadayus
### Given real assertions
| change | reason |
|---|---|
| new `Objdetect_CheckChessboard.accuracy` (`test_checkchessboard.cpp`) | `cv::checkChessboard`'s only validation lived inside a test named `timing`, which aborted at the first of 19 images. The new test iterates all 19 from `chessboard_timing_list.dat` with `SCOPED_TRACE` and `EXPECT_EQ`, so every image is reported instead of stopping at the first mismatch |
| deleted `test_chesscorners_timing.cpp` | what remained after extracting the assertions was a stopwatch — it measured `findChessboardCorners` and asserted nothing about the result |
### Re-enabled - the reason for disabling no longer holds
| test | reason |
|---|---|
| `Charuco.testSeveralBoardsWithCustomIds` (`test_charucodetection.cpp:922`) | disabled by #24338 because 5.x returns charuco corners as `32FC2` rather than `2×32FC1` (#23473). The test never compares shapes: it asserts `expected_corners.total() == c_corners.total() * c_corners.channels()` and then compares `expected_corners.reshape(1, 1)` against `c_corners.reshape(1, 1)` — both flattened to one row, so the channel layout cannot affect the result. The comparison was already made shape-agnostic; only the `DISABLED_` prefix was never removed |
### 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
Linear and Flex attention layers support - #29624
### 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
Add Image Decoder ONNX Layer - #29785
### 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
features: re-enable & triage DISABLED tests - #29752
Requires: https://github.com/opencv/opencv_extra/pull/1404
### PR Changes:
### features test cleanup
### Re-enabled
- `Features2d_Detector_MSER.regression` (`test_detectors_regression.cpp:47`). Two things were needed:
- `MSER_Impl` overrides `detect()` and had dropped the empty-image guard its base class carries, so the
harness's 0x0 probe reached `detectRegions`, which rejects anything under 3x3. Added the guard; FAST and GFTT
already carry the identical block.
- The stored baseline held 215 keypoints against the 210 MSER finds today. The drift comes from
`minDiversity` entering region rejection in `fa73b91e39` and the later `fitEllipse` rework.
### 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
Enabled WarpAffine and WarpPerspective for IPP HAL - #29771
PR enables Warp* functions that were switched off before. The thing is that I added clear 1 for places that agrees with OpenCV due to the changes in OpenCV. Also restrict the transparent border since OpenCV and IPP differently process transparent border with a workaround for current ICV package since it fails on Windows as it was mentioned in https://github.com/opencv/opencv/pull/29669#issuecomment-5339331722.
Locally the `Imgproc_WarpPerspective_Test.accuracy` test passed with ICV that is automatically downloaded by CMake.
### 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
It was warning:
Implicit conversion turns floating-point number into integer: 'float' to 'unsigned int'
when assigning to `worst_score`.
Looks to me like `worst_score` is actually being given the wrong type, and that it should have the same type as `hamming_distance`, which is `DistanceType`.
It order to test, fixed a few adjacent -Wfloat-conversion warnings in translation units that use lsh_index.h.
Fix Python utility compatibility issues - #29755
### Problem
Several repository Python utilities emit invalid escape sequence
SyntaxWarnings under Python 3.13.
The Java test checker also attempts to parse non-Java assets as UTF-8,
causing UnicodeDecodeError, and relies on a global parser instance.
The Apple build utility accepts malformed CMake version strings because
one version separator is an unescaped regex wildcard.
### Changes
- Use raw strings for regular expressions and replacement templates.
- Skip non-Java files in the Java test checker.
- Use the current JavaParser instance instead of global state.
- Require literal dots in parsed CMake versions.
### Verification
- Compiled every tracked Python file with SyntaxWarning treated as an error.
- Ran the Java checker against modules/java/test successfully.
- Verified valid CMake versions are accepted and malformed versions rejected.
- Ran git diff --check.
The system-HarfBuzz probe referenced only hb_raster_draw_create_or_fail()
and hb_raster_draw_render(), while modules/imgproc/src/drawing_text.cpp
calls ten hb_raster_* entry points. A HarfBuzz that declares the whole
hb-raster API in its header but exports only part of it passes the probe,
so OpenCV links against it instead of falling back to the bundled copy,
and the build then fails with
undefined reference to `hb_raster_draw_destroy'
Reference all ten symbols in the probe. The array is volatile because the
check compiles at -O3: a plain function address is never null, so the
compiler folds the test away and emits no relocations, which lets a
partial library pass.
Closes#29458
dnn: vectorize fast_norm for scalable-vector (RVV) targets - #29598
### Problem
The normalization CPU kernels in `fast_norm.cpp` run **scalar** on RISC-V RVV
scalable-vector builds. Their vector code is gated by `#if CV_SIMD`, and on scalable
targets `intrin.hpp` sets `CV_SIMD 0` / `CV_SIMD_SCALABLE 1`, so the blocks are dropped by
the preprocessor. LayerNorm / RMSNorm / InstanceNorm / GroupNorm / MVN are therefore scalar
there. Independently, the `#if CV_SIMD` blocks only covered the block-layout path — the NCHW
paths these layers actually use had no explicit SIMD, and the compiler does not
auto-vectorize them (the per-element `j/step` channel-index division in the GroupNorm apply
and the float→double widening reduction defeat it).
These kernels are the last scalar piece of the new-engine (`ENGINE_NEW`) transformer norm
path; they are shared by the classic engine as well.
### Changes
- Guards → `#if (CV_SIMD || CV_SIMD_SCALABLE)` (6 sites; f64 →
`#if CV_SIMD_64F || CV_SIMD_SCALABLE_64F`), no fixed-width `::nlanes` — same idiom already
used across `modules/dnn/src`.
- Vectorized the NCHW mean/variance reduction (new `normAccumSumSqSum` /
`normAccumSumSqSum64f`, float/double accumulators matching the scalar reference) and the
affine-apply loops.
- `fastNormGroup` apply hoists the per-channel scale/bias out of the inner loop so the
`j/step` division no longer blocks vectorization.
### Testing — SpacemiT K1 (rv64gcv, VLEN=256, 8×1.6 GHz, governor=performance), 5.x
Built `-DCPU_BASELINE=RVV -DRISCV_RVV_SCALABLE=ON`.
**Correctness — zero new failures.** Default `ENGINE_AUTO`:
| Filter | baseline | patch |
|---|---|---|
| `*LayerNorm*:*InstanceNorm*:*MVN*:*Norm*:*GroupNorm*` | 27/27 pass | 27/27 pass |
| `*Test_ONNX_layers*` | 263 pass / 1 fail (`Tile`, pre-existing) | 263 pass / 1 fail (`Tile`) |
Re-run with `OPENCV_FORCE_DNN_ENGINE=2` : the supported subset
(LayerNorm/InstanceNorm/GroupNorm) passes on both baseline and patch (MVN is not implemented
in the new engine and falls back to classic under AUTO).
**Performance** — `opencv_perf_dnn`, geomean of 3 rounds:
| Test | shape | base ms (1thread / 8threads) | patch ms (1t / 8t) | speedup (1t / 8t) |
|---|---|---|---|---|
| GroupNorm::Layer | {2,64,180,240}, g=16 | 104.6 / 14.36 | 12.93 / 10.75 | **8.1×** / 1.34× |
| InstanceNorm::Layer | {2,64,180,240} | 52.96 / 11.76 | 13.63 / 10.72 | **3.9×** / 1.10× |
| LayerNorm::Layer | {1,50,768} | 0.215 / 0.072 | 0.104 / 0.068 | **2.1×** / ~1.0× |
New engine confirmed directly via `readNetFromONNX(layernorm.onnx, ENGINE_NEW)`: 1×512×768
single-thread 2.74 → 1.62 ms (**1.69×**); a base-vs-patch delta under `ENGINE_NEW` proves the
new engine executes the changed kernel.
### 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
ptcloud: fix NaN bypass in TSDF volume integration bounds check - #29766Fixes#29763.
A singular or near-singular `cameraPose` makes `Matx44f::inv()` return NaN. That NaN reaches the SIMD bounds check in `integrateTsdfVolumeUnit()`, which rejects out-of-range pixels by ORing `v_lt(pt, 0)` with `v_ge(pt, upLimits)`. Under IEEE 754 both comparisons return false for NaN, so the check lets it through silently. `v_floor(NaN)` then produces an indefinite integer value (`INT_MIN` on x86), and the resulting row/column index reads out of bounds in `v_load_low()`.
Added `v_not_nan()` to the mask so a NaN lane is always treated as out of range, matching the NaN-guard idiom already used elsewhere in OpenCV (e.g. `bilateral_filter.simd.hpp`). The scalar fallback of the same function goes through `bilinearDepth()` in `tsdf_functions.hpp`, which had the identical gap (`pt.x < 0 || pt.x >= ...` also can't catch NaN), so that's covered too. Added a regression test using the singular pose from the issue's reproducer; note it can only confirm no voxel gets corrupted, not the crash itself, since that needs ASan on x86 to reproduce reliably.
### 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 (`5.x`, `ptcloud` doesn't exist on `4.x`)
- [x] There is a reference to the original bug report and related work (#29763)
- [x] There is an accuracy test (`Volume.issue_29763`), self-contained (no `opencv_extra` test data needed); not applicable: performance test (not a perf-sensitive change)
- [x] N/A: this is a bug fix, not a new feature -- no new public API or documentation needed
Dynamic KV-cache support - #29642
The core idea is: reserveKVCache() API to pre-allocate memory for attention caches upfront, which eliminates allocation overhead during token decoding. For LLM inference, simply call reserveKVCache(prompt_len + max_new_tokens) before the prefill stage so the decode loop runs without page allocations, significantly reducing per-token latency for models like Gemma3 and Qwen.
Speedups after this PR on AMD Ryzen 9 9950X 16-Core Processor device:
Qwen2.5-0.5B-Instruct, fp32, CPU, tok/s:
```
Tokens Before After Speedup
64 12.49 23.72 1.90×
128 10.37 23.14 2.23×
256 7.20 22.40 3.11×
512 4.25 21.03 4.95×
```
Gemma 3 1B-it, fp32, CPU, 512 tokens :
```
Tokens Before After Speedup
64 6.99 11.84 1.69×
128 5.84 11.72 2.01×
256 4.17 11.50 2.76×
512 2.47 11.15 4.51×
```
### 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
calib: re-enable & triage DISABLED_ tests - #29743
**co-authored by: @varun-jaiswal17**
### PR Changes:
### calib test cleanup
### Removed
- `cameraCalibrationTiltTest.projectPoints` / `.undistortPoints` (`test_cameracalibration_tilt.cpp`, 217 lines
removed): byte-identical duplicates of the copies in `geometry/test/test_cameras.cpp`, left behind when
`99fc573913` moved them out of calib. The geometry copies remain.
- `test_modelest.cpp` (231 lines, removed entirely): includes `_modelest.h` and subclasses `CvModelEstimator2`,
both of which are gone from the tree, so it cannot compile. A byte-identical copy under
`modules/geometry/test/` is removed in a companion PR.
### Re-enabled
- `Calib3d_CalibrateCamera_CPP.accuracy_on_artificial_data` (`test_cameracalibration_artificial.cpp:430`):
restored `CALIB_FIX_K3`, commented out since at least 2011 with no reason given. With `k1`, `k2` and `k3` all
free, radial distortion imitates focal length and LM settles in a local minimum on exact synthetic data,
putting `fx` about 20% off; with the flag it converges correctly.
Three further fixes in the same test:
- `reprojectErrorWithoutIntrinsics` indexed `uv_exp[i]` inside a loop over `j`, so it summed one corner's
error repeatedly instead of averaging over all of them.
- The `rep_error` check was unreachable: `calibrateCamera` already returns a per-point RMS, and the test
divided it by the point count again before comparing, so a 1.57 px RMS passed silently. The extra division is
removed.
- The board-generation retry loop was an unbounded `for(;;)`; it now fails the test after 100 attempts
instead of looping forever.
### 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
Geometry:Test cleanup - #29753
**co-authored by: @varun-jaiswal17**
### geometry test cleanup
### Removed (dead or unbuildable)
- `test_modelest.cpp` (231 lines, removed entirely): includes `_modelest.h` and subclasses `CvModelEstimator2`,
both of which are gone from the tree, so it cannot compile.
- `test_cameras.cpp:11-207` (197 lines removed): a `#if 0` block, never compiled, holding an older
`cvtest::ArrayTest`-based `CV_ProjectPointsTest` built on the removed C API (`CvMat`, `cvProjectPoints2`). A
live class of the same name derived from `cvtest::BaseTest` follows it and covers strictly more: `Rodrigues`
plus five jacobians against the dead block's two.
### Given real assertions
- `Calib3d_FindFundamentalMat.correctMatches` (`test_fundam.cpp:410`): reverting the solvePoly fix gives -nan /
1.79e+308 and it still passed.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
The Python tutorial sample thresholds the orientation with a single cv.threshold call, passing HighThr as the maxval argument rather than as an upper bound:
```_, imgOrientationBin = cv.threshold(imgOrientation, LowThr, HighThr, cv.THRESH_BINARY)```
That computes imgOrientation > LowThr ? HighThr : 0, so HighThr never restricts the angle. The C++ counterpart uses inRange(imgOrientation, Scalar(LowThr), Scalar(HighThr), imgOrientationBin), and the tutorial text states "LowThr and HighThr define orientation range", so the C++ behaviour is the intended one.
geometry: fix strict-aliasing UB in convexHull - #29714Fixes#26952.
### What
`convexHull()` allocated a single `AutoBuffer<Point*>` and obtained a `Point2f**` view of the *same storage* via `reinterpret_cast` to share the sort/`Sklansky_` code between the `CV_32S` and `CV_32F` cases, and unconditionally read the input via `points.ptr<Point>()` regardless of the Mat's actual depth. Both are strict-aliasing violations -- the exact mechanism the issue title describes ("bogus C-cast and illegal assumptions of object layout") -- and are undefined behavior independent of `Point` and `Point2f` happening to be the same size.
### Why this approach
Two prior attempts (#26975, #27020, both by @kallaballa, both open for months before stalling) tried to fix this by rewriting input/output handling around `InputArray::copyTo` and `std::vector`. That cascaded into unrelated scope -- undocumented-input-format questions, new overloaded signatures that broke Java bindings, uncertainty about what the "authoritative spec" for accepted inputs even is -- and neither landed. @asmorkalov's own diagnosis in that thread was narrower: *"the same data is casted as `Point*` and `Point2f*` and used as integer or floating point"* -- i.e. the casting itself, not the input/output handling, is the bug.
This PR makes only that minimal change. `convexHull`'s core is now a function template on the point type (`convexHull_<_Tp,_DotTp>`), so `pointer`/`data0` are always genuinely `Point_<_Tp>*`-typed for whichever branch is active -- no cast is ever needed, because the two instantiations never share storage. `Sklansky_` and `CHullCmpPoints` needed no changes at all; they were already correctly templated -- the UB was only in how the non-template `convexHull()` constructed and reinterpreted the buffers it passed to them. The public signature, input parsing, and output writing are otherwise unchanged, and no other function needed touching (`convexityDefects`/`isContourConvex` already dispatch on depth correctly).
### Testing
- All 55 existing tests covering `convexHull`, the self-intersection index-monotonicity fixup (`!returnPoints`), `minAreaRect`, `minEnclosingTriangle`, and `convexityDefects` pass unchanged -- these call `convexHull` internally, which is exactly what broke under the prior attempts' more invasive rewrites.
- **Performance** (the other thing that sank a prior attempt): my first design (switching the internal representation from a pointer array to an int index array) measured a real, consistent ~10-13% slowdown at n=10000/100000 vs pristine 5.x (A/B via `git stash`, 7-trial medians) -- traced to the extra `index * stride` address computation an index array requires on every dereference that a direct pointer dereference doesn't. Redesigned to keep the *pointer*-array representation (just correctly typed per template instantiation instead of cast), which recovered performance matching baseline within trial-to-trial noise at every size tested. Added `modules/geometry/perf/perf_convhull.cpp` as a permanent regression guard (100/1k/10k/100k points, `CV_32S`/`CV_32F`) -- no such perf test existed before, despite this being exactly the kind of change that regressed performance in prior attempts.
- Full `opencv_test_geometry` suite: no failures attributable to this change (the 3 present are pre-existing, needing `opencv_extra` test data not configured in this scoped build).
### PR 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 code under GPL or another incompatible license.
- [x] The PR is proposed to the proper branch (5.x).
- [x] Accuracy and performance tests included/added (see above).
- [x] No public API/behavior change, so no documentation or sample updates needed.
Alexander Smorkalov
Satya Mallick
Prasad Ayush Kumar
Varun Jaiswal
Victor Getmanskiy
Savya Sanchi Sharma
Abhishek Gola
Varun Jaiswal
Matt Van Horn
loulanyue
Andrei Fedorov
Sean McBride
zaveshaa
Aditya Suryawanshi
Mulham Fetna
Teddy-Yangjiale
Lazizbek Ergashev
Vincent Rabaud
bmad
CodeCraftsman