| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
video(ocl): enable cl_khr_subgroups extension in dis_flow.cl When running DIS Optical Flow on OpenCL devices supporting `cl_khr_subgroups` (such as ARM Mali GPUs), `dis_flow.cpp` detects subgroup support and appends `-DCV_USE_SUBGROUPS=1` to OpenCL kernel build options. However, `modules/video/src/opencl/dis_flow.cl` was missing `#pragma OPENCL EXTENSION cl_khr_subgroups : enable`. As a result, OpenCL kernel compilation failed with implicit function declaration errors: <source>:189:12: error: implicit declaration of function 'sub_group_reduce_add' is invalid in OpenCL sum_diff = sub_group_reduce_add(sum_diff); ^ <source>:229:11: error: implicit declaration of function 'get_sub_group_local_id' is invalid in OpenCL int sid = get_sub_group_local_id(); Fix by adding `#pragma OPENCL EXTENSION cl_khr_subgroups : enable` inside `#ifdef CV_USE_SUBGROUPS` in `dis_flow.cl`. Fixes #27507 | 24 天前 | |
video: fix the input scaling factor of TrackerVit The tracker normalizes the images it feeds to the network with Image2BlobParams, whose per-channel factor has to be 1/(255*std). It was computed as `(1.0 / stdvalue) * (1 / 255.0)`, but `double / Scalar` is Scalar's quaternion inverse, not an elementwise division, and `Scalar / Scalar` is defined through that same inverse. The last three elements were therefore conjugated and the whole result divided by their sum of squares, so with the default std = (0.229, 0.224, 0.225) the green and red planes reached the network negated and all three were about a third of the intended magnitude. Build the factor channel by channel in both create() overloads, and cover it with a test that compares the response of the network the tracker feeds against an identical network fed the documented normalization of the same template crop. | 12 天前 | |
Merge pull request #29453 from vrabaud:persistence Replace "static inline" by "inline" in headers #29453 This fixes #29436 I also replaced CV_INLINE which can be removed in a later PR. I can make a similar PR for 4.x if you want. ### 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 | 3 个月前 | |
Merge pull request #29453 from vrabaud:persistence Replace "static inline" by "inline" in headers #29453 This fixes #29436 I also replaced CV_INLINE which can be removed in a later PR. I can make a similar PR for 4.x if you want. ### 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 | 3 个月前 | |
fixed bug: added threshold for variables 'rotate_a', ' rotate_c' | 7 年前 | |
Merge pull request #29715 from Thebinary110:fix-dis-opticalflow-overflow video: fix DISOpticalFlow heap-buffer-overflow with patch_size > border_size - #29715 Fixes #20185. ### What `DISOpticalFlowImpl` pads `I1` of every pyramid level with a **fixed 16 pixel border** (`border_size`), while `PatchInverseSearch` clamps a patch's sample position to: ```cpp float i_lower_limit = bsz - psz + 1.0f; // bsz = border_size, psz = patch_size float i_upper_limit = bsz + dis->h - 1.0f; ``` i.e. a patch may be placed up to `patch_size - 1` pixels outside of the image. `computeSSD()`/`computeSSDMeanNorm()` then read `patch_size` (+1 for bilinear interpolation) rows/columns starting at that clamped position, which stays inside the padded buffer only while `patch_size <= border_size`. `patch_size` is user-settable via `setPatchSize()` with no upper bound relative to the hardcoded `border_size` -- so `setPatchSize()` past 16, or a temporal-candidate flow large enough to push the clamped search against its limit, reads past the end of `I1s_ext` (confirmed via AddressSanitizer: heap-buffer-overflow in `computeSSDMeanNorm`). ### Fix Size the border to whichever is larger, exactly once, at the top of `prepareBuffers()` (where every `I1s_ext[i]` already gets freshly created/padded on every `calc()` call, so this doesn't need any additional cache-invalidation logic): ```cpp border_size = max(16, patch_size); ``` The needed inequality (`border_size >= patch_size`) is independent of image size, so this is sufficient at every pyramid level uniformly. `ocl_prepareBuffers()` does not need the equivalent change: `calc()`'s `CV_OCL_RUN` gate only takes the OpenCL path when `patch_size == 8` exactly, which is always within the hardcoded border, so that path can never reach this overflow. ### On the prior attempt A prior attempt at this exact fix (#29600) was closed by @asmorkalov, who ran its own added regression test and got the same ASan heap-buffer-overflow again ("the patch is not efficient"). I want to be upfront about this rather than just re-submitting the same-looking diff: **I could not reproduce that failure.** I reproduced the original overflow on unfixed 5.x (same crash site / allocator stack as both the original issue report and #29600's own ASan trace), then applied the same one-line fix and ran #29600's own added test 20x plus a new 40-trial randomized stress test (`patch_size` 9-48 -- spanning above and below `border_size=16` -- varying image size, `patch_stride`, flow magnitude up to 120px, and a same-instance second `calc()` call to exercise buffer re-use across a patch-size change) under AddressSanitizer, with zero failures. I don't have a confirmed explanation for the discrepancy -- possibly a stale incremental build on the original attempt's end, since I hit and had to work around exactly that kind of false "no work to do" ninja build-cache issue myself while setting up this reproduction. Flagging this openly rather than asserting certainty either way -- happy to dig further if CI or review surfaces a case this doesn't cover. ### Testing Verified locally with a dedicated ASan-instrumented Debug build (`-fsanitize=address`, separate from the Release build used to verify the rest of today's changes), specifically because an out-of-bounds read like this often just silently returns garbage in a Release build instead of crashing: - Confirmed the crash reproduces on unfixed 5.x, and is gone with the fix, under both `regression_20185_patch_larger_than_border` (from #29600, included here) and a new `regression_20185_stress` test (40 randomized trials) -- both passing cleanly under ASan. - Re-verified both tests pass in the standard Release configuration too. - Full `opencv_test_video` suite (both ASan and Release): no failures attributable to this change; everything else failing needs `opencv_extra` test data (tracking/ECC/optical-flow reference videos/images) 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 tests included (see above). - [x] No public API/behavior change, so no documentation or sample updates needed. | 1 个月前 | |
Merge pull request #29681 from Neal006:video/ecc-bool-mask video: accept CV_Bool masks in findTransformECC (#25895) #29681 ### Problem `cv::Mat_<bool>::depth()` returns `CV_Bool` in 5.0, where it returned `CV_8U` in 4.x. `findTransformECCWithMask` does not type check `inputMask` at all. It passes it straight to `cv::threshold()` at `ecc.cpp:483`, and `cv::threshold()` dispatches only on `CV_8U`, `CV_16S`, `CV_16U`, `CV_32F` and `CV_64F`, erroring otherwise. So a boolean mask fails with an error pointing at imgproc rather than at the mask: ``` modules/imgproc/src/thresh.cpp:1607: error: (-210:Unsupported format or combination of formats) in function 'cv::threshold' ``` ### Fix Widen a `CV_Bool` mask to `CV_8U` before the `threshold` call. The existing `THRESH_BINARY` step then treats any non-zero entry as selected, which matches the `CV_8U` mask semantics. `inputMask` is used nowhere else in the function (only at `ecc.cpp:476` for the `empty()` check and at `:483`), so this is the single point that needed handling. `CV_8U` masks take an unchanged path. Note that `cv::computeECC` already accepts a boolean mask, because it only forwards the mask to `countNonZero`, `meanStdDev` and `subtract`, which all handle `CV_Bool`. This change makes `findTransformECC` consistent with it. ### Test `Video_ECC_BoolMask.matches_uchar_mask` builds a blurred checkerboard, warps it by a known translation, then runs `findTransformECC` with `MOTION_TRANSLATION` using a `Mat_<bool>` mask and the equivalent `CV_8UC1` mask, and requires the same warp matrix from both. Verified locally on 5.x: the test fails without the change (with the error above) and passes with it. The full `*ECC*` set, 15 tests, passes with `OPENCV_TEST_DATA_PATH` set. No test data needed for the new test itself, it is synthetic. Part of #25895, and follows the same approach as #29580, #29597 and #29622. ### Pull Request Readiness Checklist - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch - [x] There is a reference to the original bug report and related work - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable 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 | 2 个月前 | |
Merge pull request #29148 from 4ekmah:eccms_fixpython Fixing python wrapper around ECCParameters to include itersPerLevel #29148 ### 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 个月前 | |
Added HAL documentation note for out-of-bound hack in optical flow LK. | 2 年前 | |
Fix KalmanFilter comment error If there will be measurement before the next predict, `statePost` would be assigned to updated value. So I guess these steps are meant to handle when no measurement and KF only do the predict step. ```cpp statePre.copyTo(statePost); errorCovPre.copyTo(errorCovPost); ``` | 4 年前 | |
Merge pull request #29947 from Xlawy:opt/rvv-pyrlk-tracker video:rvv: optimize PyrLK tracker with RVV - #29947 ### Summary Add an RVV path to `LKTrackerInvoker` for patch interpolation and covariance matrix accumulation. ### Implementation Vectorize bilinear interpolation of image pixels and derivatives, and accumulate A11, A12 and A22 using RVV widening operations. Reuse temporary vectors and keep the main computation at `e16,m1` and `e32/f32,m2` to limit vector register pressure. ### Functional Testing ```bash ./bin/opencv_test_video \ --gtest_filter='Video_OpticalFlowPyrLK.accuracy' \ --test_threads=1 ./bin/opencv_test_video \ --gtest_filter='Video_OpticalFlowPyrLK.submat' \ --test_threads=1 ``` Correctness was verified with: - `Video_OpticalFlowPyrLK.accuracy` - `Video_OpticalFlowPyrLK.submat` ### Performance Testing ```bash OPENCV_FOR_THREADS_NUM=1 \ ./bin/opencv_perf_video \ --gtest_filter='*OpticalFlowPyrLK_self*' \ --perf_threads=1 ``` Performance was measured with `OpticalFlowPyrLK_self` using a single thread on an RVV 1.0 system with VLEN=256. All 96 benchmark cases improved with no regression. The sum of per-case median execution times decreased from 409.89 ms to 332.33 ms, a reduction of 18.9%. The best case decreased from 8.41 ms to 5.50 ms, corresponding to a 34.6% reduction in execution time (1.53x speedup). Median execution time (ms): | Metric | Baseline | RVV | Time reduction | |---|---:|---:|---:| | Sum of per-case medians across all 96 cases | 409.89 | 332.33 | 18.9% | | Best case | 8.41 | 5.50 | 34.6% | ### Co-authors - Yang Wang <yangwang@iscas.ac.cn> - Yuansheng <yuansheng@iscas.ac.cn> ### 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 - [ ] 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 | 1 个月前 | |
Merge pull request #28632 from amd:fast_scharr_deriv video: Optimized ScharrDeriv#28632 - Move to CV_SIMD_SCALABLE - avx2 & avx512 dispatch added for ScharrDeriv ### 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 | 7 个月前 | |
Merge pull request #28632 from amd:fast_scharr_deriv video: Optimized ScharrDeriv#28632 - Move to CV_SIMD_SCALABLE - avx2 & avx512 dispatch added for ScharrDeriv ### 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 | 7 个月前 | |
Merge pull request #28632 from amd:fast_scharr_deriv video: Optimized ScharrDeriv#28632 - Move to CV_SIMD_SCALABLE - avx2 & avx512 dispatch added for ScharrDeriv ### 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 | 7 个月前 | |
Merge pull request #29989 from vrabaud:variant Add compile-time fast paths for _InputArray/_OutputArray | 24 天前 | |
fix: supress GCC13 warnings (#24434) * fix: supress GCC13 warnings * fix for review and compile-warning on MacOS | 2 年前 | |
Merge pull request #29230 from asmorkalov:as/move_undistort Inverted imgproc-geometry dependency and moved more functions to geometry #29230 Fixes: https://github.com/opencv/opencv/issues/20267 Continues: https://github.com/opencv/opencv/pull/29175 OpenCV Contrib: https://github.com/opencv/opencv_contrib/pull/4137 OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1377 Summary: - LSD returned back to imgproc - drawing functions moved to imgproc - undistort image and related perf-pixel functions moved to imgproc - moments moved to geometry - estimateXXXtransform moved to geometry After the patch the geometry module depends on code and Flann and may be used everywhere without potential circular dependencies ### 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 | 4 个月前 | |
video: migrate VariationalRefinement SIMD kernels to universal/scalable intrinsics Port of #29862 (merged into 4.x) to 5.x. - Type/stride substitution only; arithmetic and evaluation order unchanged. - RedBlackSOR: the v_extract<3>(prev, next) previous-lane construction is replaced by an unaligned vx_load(p_next + j - 1); v_extract<3> is only previous-lane when vlanes == 4, so this is required for wider lanes. - HorPass keeps a strict bound, j < len - vlanes, while the other three use j <= len - vlanes, since the vector body applies UPDATE to every lane and the rightmost element must not receive UPDATE across the right border. - No SVE claim: there is no SVE backend in-tree; scalable means RVV today. | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 24 天前 | ||
| 12 天前 | ||
| 3 个月前 | ||
| 3 个月前 | ||
| 7 年前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 5 个月前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 1 个月前 | ||
| 7 个月前 | ||
| 7 个月前 | ||
| 7 个月前 | ||
| 24 天前 | ||
| 2 年前 | ||
| 4 个月前 | ||
| 1 个月前 |