| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Merge pull request #30274 from LukaszJobczyk/port-ocl-color-vload4-overread-5.x imgproc: fix out-of-bounds read in OpenCL color kernels for 3-channel input 🤖🤖🤖 - #30274 YUV2RGB, RGB2YCrCb, YCrCb2RGB and the PIX_PER_WI_X != 2 path of RGB2YUV_YV12_IYUV load each source pixel with vload4 but only use the first three components. With SCN == 3 the load of the last pixel reads one element past the end of the source buffer, which may result in a GPU page fault. Use vload3, as RGB2YUV already does, and drop the now unused DATA_TYPE_4 macro. The same issue is fixed in RGB2XYZ, XYZ2RGB, BGR2Lab, Lab2BGR, RGB2HSV, HSV2RGB, RGB2HLS, HLS2RGB and RGB2RGB5x5, which load each source pixel with vload4 but only use the first three components when SCN == 3. Add an OpenCL cvtColor test with a contiguous 3-channel source whose size is a multiple of 1 MiB, so the last pixel ends exactly at the end of the buffer, covering 8U and 32F conversions and RGB2RGB5x5. ### 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 | 19 天前 | |
Merge pull request #29784 from abhishek-gola:alpha_composite Alpha composite support - #29784 closes: https://github.com/opencv/opencv/issues/20780 https://github.com/opencv/opencv/issues/13135 https://github.com/opencv/opencv/issues/23706 ### 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 | 27 天前 | |
Merge pull request #28259 from falloficarus22:fix/bilateral-filter-oob Fix the out-of-bounds read in cv::bilateralFilter for 32f images #28259 ### Root Cause Analysis The issue was caused by a discrepancy between the image range used to allocate the color weight look-up table (LUT) and the actual range of pixel values encountered during filtering, especially near the image borders. - Range Computation: `cv::bilateralFilter` computes the min/max values of the source image and allocates a `LUT (expLUT)` of size `kExpNumBins + 2` based on this range. - Border Padding: If `cv::BORDER_CONSTANT` is used (defaulting to 0), and 0 is outside the image's original range (e.g., an image with values between 100 and 200), the padded image will contain values (0) that create differences larger than those accounted for in the `LUT`. - Out-of-Bounds Access: When calculating the color weight, the code computes an index `idx` from the absolute difference. If this difference exceeds the expected range, `idx` can reach or exceed `kExpNumBins + 1`. Since the code performs linear interpolation using `expLUT[idx]` and `expLUT[idx + 1]`, an `idx` of `kExpNumBins + 1` causes an access to `expLUT[kExpNumBins + 2]`, which is out of bounds. ### Fix I implemented a robust clamping mechanism in both the SIMD (AVX/SSE) and scalar paths of the bilateral filter invoker: - Signature Update: Updated `bilateralFilterInvoker_32f` to accept `kExpNumBins` (the maximum valid `LUT` index). - Clamping: Clamped the computed color difference (alpha) to `kExpNumBins` before calculating the `LUT` index. This ensures that any difference exceeding the planned range is safely treated as the maximum difference in the `LUT` (which usually corresponds to a weight of 0), avoiding any out-of-bounds memory access. ### Modified Files Modified Files: `modules/imgproc/src/bilateral_filter.simd.hpp`: Updated the invoker class and SIMD/scalar loops to clamp the LUT index. `modules/imgproc/src/bilateral_filter.dispatch.cpp`: Updated the dispatch call site to pass the correct LUT size. Closes #28254 ### 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 | 10 个月前 | |
Merge branch 4.x | 2 年前 | |
Merge pull request #30286 from vrabaud:fuzztest_fixes Fix code according to fuzzer findings - #30286 ### 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 | 14 天前 | |
Merge pull request #30225 from varun-projects:fix/issue-29854-connectedcomponents-empty imgproc: fix segfault in connectedComponents on zero-size input - #30225 `cv::connectedComponents` and `cv::connectedComponentsWithStats` crash with SIGSEGV when passed an image with a zero-length dimension (e.g., shape `(0, 400)`), instead of raising a proper error. All other OpenCV functions handle empty input gracefully. The root cause is that the labeling algorithms dereference pointers based on image dimensions without first checking for empty input, causing a null dereference when `rows == 0` or `cols == 0`. The fix adds `CV_Assert(!img.empty())` at the entry point of both public API functions, so callers receive a `cv::Exception` / `cv2.error` consistently with the rest of the OpenCV API (`findContours`, `cvtColor`, `inRange`, etc.). A regression test `Imgproc_ConnectedComponents.empty_input_29854` is included, covering all three zero-dimension shapes (`{0,400}`, `{400,0}`, `{0,0}`) for both `connectedComponents` and `connectedComponentsWithStats`. Reproducer: ```python import numpy as np, cv2 mask = np.zeros((0, 400), dtype=np.uint8) cv2.connectedComponentsWithStats(mask) # was: SIGSEGV; now: cv2.error ``` Fixes #29854 | 21 天前 | |
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 个月前 | |
imgproc: contours C-API cleanup | 2 年前 | |
Merge pull request #28773 from rmsalinas:imgproc_find_truco_contours imgproc: add findTRUContours - lock-free parallel contour extraction #28773 Integrates the TRUCO algorithm (Threaded Raster Unrestricted Contour Ownership, @cite TRUCO2026) as a transparent fast path inside `cv::findContours`. No API change is required: existing code automatically benefits when `mode=RETR_LIST` and no hierarchy output is requested. ### How it works When `mode=RETR_LIST` and the caller does not request hierarchy, `findContours` delegates to the TRUCO parallel engine instead of Suzuki-Abe. All ContourApproximationModes are supported; approximation is applied in parallel after extraction. In all other cases the original Suzuki-Abe path is used unchanged. ### Key design ideas - Row-strip domain decomposition parallelised via `cv::parallel_for_` - Start-point ownership rule + speculative downward tracing eliminate tile stitching and synchronisation primitives (lock-free) - 8-bit state space instead of the 32-bit integer labeling required by Suzuki-Abe, giving higher SIMD throughput and lower memory-bandwidth pressure - Paged contour buffer (`TRUCOPagedContour`) avoids heap reallocation on the hot tracing path - SIMD-accelerated row scanning via `cv::v_uint8` intrinsics - Thread count controlled globally via `cv::setNumThreads()`, consistent with OpenCV conventions ### Output correctness Significant effort has gone into ensuring the output is identical to the original `findContours` in every respect: same contour set, same ordering, and same approximation results for all methods. A dedicated test suite (`test_contours_truco.cpp`) verifies exact match against Suzuki-Abe across all four `ContourApproximationModes` and thread counts from 1 to 39, using noise images, circles, nested rectangles, and mixed scenes. ### Performance vs. Suzuki-Abe (from submitted paper) - single-thread: ~1.8–1.9× faster (8-bit SIMD advantage) - 20 threads: ~14–20× faster on i7-13700H (6P+8E, 20T) - 20 threads: ~10–12× faster on Xeon Silver 4510 (12C/24T) ### 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 | 5 个月前 | |
Merge pull request #27418 from dkurt:fix_valgrind_warnings Fix valgrind warnings in tests #27418 ### Pull Request Readiness Checklist https://pullrequest.opencv.org/buildbot/builders/4_x_valgrind-lin64-debug/builds/100131/steps/test_calib3d/logs/valgrind%20summary https://pullrequest.opencv.org/buildbot/builders/4_x_valgrind-lin64-debug/builds/100131/steps/test_imgproc/logs/valgrind%20summary 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 | 1 年前 | |
Merge pull request #24333 from definitelyuncertain:CvtRGB2YUV422 Implement color conversion from RGB to YUV422 family #24333 Related PR for extra: https://github.com/opencv/opencv_extra/pull/1104 Hi, This patch provides CPU and OpenCL implementations of color conversions from RGB/BGR to YUV422 family (such as UYVY and YUY2). These features would come in useful for enabling standard RGB images to be supplied as input to algorithms or networks that make use of images in YUV422 format directly (for example, on resource constrained devices working with camera images captured in YUV422). The code, tests and perf tests are all written following the existing pattern. There is also an example `bin/example_cpp_cvtColor_RGB2YUV422` that loads an image from disk, converts it from BGR to UYVY and then back to BGR, and displays the result as a visual check that the conversion works. The OpenCL performance for the forward conversion implemented here is the same as the existing backward conversion on my hardware. The CPU implementation, unfortunately, isn't very optimized as I am not yet familiar with the SIMD code. Please let me know if I need to fix something or can make other modifications. Thanks! ### 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 - [x] The feature is well documented and sample code can be built with the project CMake | 3 年前 | |
imgproc: accept CV_Bool masks in distanceTransform cv::Mat_<bool>::depth() returns CV_Bool in 5.0 where it returned CV_8U in 4.x, so distanceTransform started rejecting boolean masks. CV_Bool is a 1-byte type whose values are only zero-tested here, so accept it wherever a CV_8UC1 mask was previously accepted, matching the 4.x behaviour and the 4->5 migration guide. Relaxes the type checks on all four reachable paths: the public wrapper, distanceTransform_L1_8U, trueDistTrans (DIST_MASK_PRECISE) and distanceATS_L1_8u (CV_8U output). Closes #29596 | 3 个月前 | |
imgproc: shrink the text rendering footprint (HarfBuzz -Os, optional built-in fonts) libopencv_imgproc grew noticeably with the HarfBuzz-based text engine. Measured on macOS/arm64 (clang, Release, stripped) the text-related part of the library was ~830 KB: HarfBuzz 486 KB, the two Rubik fonts 296 KB, the engine ~25 KB, plus ~2 MB of WenQuanYi when WITH_UNIFONT=ON (the previous default). With GCC and an unstripped .so on Linux the HarfBuzz part alone is 700+ KB. This patch brings it down to ~550 KB by default (HarfBuzz 377 KB + Rubik 146 KB + engine 30 KB) without dropping functionality: * 3rdparty/harfbuzz: build with -Os -fno-exceptions -fno-rtti -fno-threadsafe-statics (like HarfBuzz's own build; shaping speed is irrelevant thanks to the glyph cache) and HB_NO_VAR_COMPOSITES (VARC table, a 2024 format with no real fonts yet). Variable-font support (wght axis etc.) is untouched. -22% of HarfBuzz code. * Only the "sans" font (Rubik) is compiled into imgproc by default. Rubik Italic and WenQuanYi Micro Hei became optional: WITH_ITALICFONT (new) and WITH_UNIFONT are both OFF now. The build summary lists the built-in fonts. * New API cv::FontFace::setBuiltinFont(name, path) fills or replaces any of the three built-in slots ("sans", "italic", "uni") with an external font file. The registered font takes part in the automatic fallback chain exactly like a compiled-in one, so users can get CJK text or a true italic without rebuilding OpenCV. The registry is process-wide; each thread's engine reloads its slots lazily (generation counter), and the glyph cache is dropped on reload since hb_font pointers are part of its key. * "italic" resolves to "sans" when no italic font is built in or registered, so FONT_ITALIC / FONT_HERSHEY_SCRIPT_* in the legacy putText keep working (upright). * Fix: a character not covered by any font used to be drawn as '?' taken from the last built-in slot, which can be empty now; the '?' is looked up like any other character (user font first). * Tests: opencv_test_imgproc registers Rubik-Italic.ttf.gz and WenQuanYiMicroHei.ttf.gz from opencv_extra (testdata/highgui/drawing) as the "italic"/"uni" slots, so Drawing.ttf_text reproduces the reference picture 1:1 with the default build and the legacy hershey-font tests are unchanged. Drawing.builtin_font_slots covers the new API. Tests skip if the fonts are absent. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> | 1 个月前 | |
Merge pull request #25469 from mshabunin:cpp-emd imgproc: refactor EMD to reduce C-API usage #25469 - added more tests for EMD - refactored to remove CvArr - used BufferArea for memory allocations - renamed functions and variables and formatted the code - kept legacy functions intact in separate header | 2 年前 | |
Merge pull request #29799 from lazerg:fix/issue-29798-dilate-bool imgproc: accept CV_Bool input in morphological operations - #29799 ### Pull Request Readiness Checklist Fixes #29798 In 5.0 `cv::Mat_<bool>::depth()` returns `CV_Bool` instead of `CV_8U`, so the morphology filter factories in `morph.simd.hpp` no longer matched any branch and threw `Unsupported data type`. This worked in 4.x. `CV_Bool` is a 1-byte 0/1 type, so it is dispatched through the same `uchar` min/max filters as `CV_8U`, and the default border value follows the `CV_8U` case (1 for erode, 0 for dilate). The OpenCL path bails out for `CV_Bool` and falls back to the CPU implementation, since `ocl::typeToStr` has no mapping for it. Accepting `CV_Bool` also exposed a latent bug in `FilterEngine::init`: `borderElemSize` was computed from `CV_MAT_DEPTH(srcType) >= CV_32S`, which assumes the depth enum is ordered by element size. `CV_Bool` is 9, so a 1-byte type took the `sizeof(int)` branch and `borderElemSize` became 0, leaving `borderTab` empty and making every non-`BORDER_CONSTANT` erode/dilate read through a null pointer. It now keys off `CV_ELEM_SIZE1` instead. `CV_16F`/`CV_16BF` had the same latent miscomputation. Added a test comparing `Mat_<bool>` against the equivalent `CV_8UC1` mask for erode, dilate, open and close over the three structuring element shapes and four border types, plus in-place and multi-iteration calls. `MORPH_GRADIENT`/`TOPHAT`/`BLACKHAT` remain unsupported for `CV_Bool`: they subtract two masks, which has no meaning for a boolean type, and they throw rather than returning a wrong result. 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 | 10 天前 | |
Merge pull request #22754 from mshabunin:c-cleanup C-API cleanup for OpenCV 5.x (imgproc, highgui) * imgproc: C-API cleanup * imgproc: increase cvtColor test diff threshold * imgproc: C-API cleanup pt.2 * imgproc: C-API cleanup pt.3 * imgproc: C-API cleanup pt.4 * imgproc: C-API cleanup pt.5 * imgproc: C-API cleanup pt.5 * imgproc: C-API cleanup pt.6 * highgui: C-API cleanup * highgui: C-API cleanup pt.2 * highgui: C-API cleanup pt.3 * highgui: C-API cleanup pt.3 * imgproc: C-API cleanup pt.7 * fixup! highgui: C-API cleanup pt.3 * fixup! imgproc: C-API cleanup pt.6 * imgproc: C-API cleanup pt.8 * imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 | 3 年前 | |
Check for empty Mat in compare, operator= and RNG::fill, fixed related tests | 8 年前 | |
Merge pull request #30342 from Vaishnavi220506:Vaishnavi220506/fix/sparse-histogram-chi-square-5x | 14 天前 | |
Merge pull request #22754 from mshabunin:c-cleanup C-API cleanup for OpenCV 5.x (imgproc, highgui) * imgproc: C-API cleanup * imgproc: increase cvtColor test diff threshold * imgproc: C-API cleanup pt.2 * imgproc: C-API cleanup pt.3 * imgproc: C-API cleanup pt.4 * imgproc: C-API cleanup pt.5 * imgproc: C-API cleanup pt.5 * imgproc: C-API cleanup pt.6 * highgui: C-API cleanup * highgui: C-API cleanup pt.2 * highgui: C-API cleanup pt.3 * highgui: C-API cleanup pt.3 * imgproc: C-API cleanup pt.7 * fixup! highgui: C-API cleanup pt.3 * fixup! imgproc: C-API cleanup pt.6 * imgproc: C-API cleanup pt.8 * imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 * fixup! imgproc: C-API cleanup pt.9 | 3 年前 | |
Merge pull request #30286 from vrabaud:fuzztest_fixes Fix code according to fuzzer findings - #30286 ### 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 | 14 天前 | |
Merge pull request #29740 from varun-jaiswal17:imgproc_cleanup 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 | 2 个月前 | |
imgproc: don’t use ippiCopySubpixIntersect for windows crossing the image border - #30363 | 11 天前 | |
Merge pull request #29165 from vpisarev:better_bicubic Revised bicubic interpolation kernels and updated the corresponding functions #29165 They should work more accurately and faster than the existing implementation. The PR follows the previous work (#26271 etc.) that brought faster bilinear kernels. ### Pull Request Readiness Checklist See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch - [x] There is a reference to the original bug report and related work - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name. - [ ] The feature is well documented and sample code can be built with the project CMake | 4 个月前 | |
Merge pull request #29948 from vrabaud:comma_initializer Remove deprecated CommaInitializer API - #29948 This goes hand in hand with https://github.com/opencv/opencv_contrib/pull/4217 ### 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 | 1 个月前 | |
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 个月前 | |
imgproc: shrink the text rendering footprint (HarfBuzz -Os, optional built-in fonts) libopencv_imgproc grew noticeably with the HarfBuzz-based text engine. Measured on macOS/arm64 (clang, Release, stripped) the text-related part of the library was ~830 KB: HarfBuzz 486 KB, the two Rubik fonts 296 KB, the engine ~25 KB, plus ~2 MB of WenQuanYi when WITH_UNIFONT=ON (the previous default). With GCC and an unstripped .so on Linux the HarfBuzz part alone is 700+ KB. This patch brings it down to ~550 KB by default (HarfBuzz 377 KB + Rubik 146 KB + engine 30 KB) without dropping functionality: * 3rdparty/harfbuzz: build with -Os -fno-exceptions -fno-rtti -fno-threadsafe-statics (like HarfBuzz's own build; shaping speed is irrelevant thanks to the glyph cache) and HB_NO_VAR_COMPOSITES (VARC table, a 2024 format with no real fonts yet). Variable-font support (wght axis etc.) is untouched. -22% of HarfBuzz code. * Only the "sans" font (Rubik) is compiled into imgproc by default. Rubik Italic and WenQuanYi Micro Hei became optional: WITH_ITALICFONT (new) and WITH_UNIFONT are both OFF now. The build summary lists the built-in fonts. * New API cv::FontFace::setBuiltinFont(name, path) fills or replaces any of the three built-in slots ("sans", "italic", "uni") with an external font file. The registered font takes part in the automatic fallback chain exactly like a compiled-in one, so users can get CJK text or a true italic without rebuilding OpenCV. The registry is process-wide; each thread's engine reloads its slots lazily (generation counter), and the glyph cache is dropped on reload since hb_font pointers are part of its key. * "italic" resolves to "sans" when no italic font is built in or registered, so FONT_ITALIC / FONT_HERSHEY_SCRIPT_* in the legacy putText keep working (upright). * Fix: a character not covered by any font used to be drawn as '?' taken from the last built-in slot, which can be empty now; the '?' is looked up like any other character (user font first). * Tests: opencv_test_imgproc registers Rubik-Italic.ttf.gz and WenQuanYiMicroHei.ttf.gz from opencv_extra (testdata/highgui/drawing) as the "italic"/"uni" slots, so Drawing.ttf_text reproduces the reference picture 1:1 with the default build and the legacy hershey-font tests are unchanged. Drawing.builtin_font_slots covers the new API. Tests skip if the fonts are absent. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> | 1 个月前 | |
preserve phaseCorrelate inputs when windowing | 17 天前 | |
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 个月前 | |
fix the right border | 4 年前 | |
Merge pull request #29948 from vrabaud:comma_initializer Remove deprecated CommaInitializer API - #29948 This goes hand in hand with https://github.com/opencv/opencv_contrib/pull/4217 ### 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 | 1 个月前 | |
Post-merge fixes for algorithm hint API. | 2 年前 | |
Merge pull request #28250 from satyam102006:fix/stackblur-overflow-28233 imgproc: fix heap-buffer-overflow in stackBlur #28233 #28250 ### Summary Fixes a heap-buffer-overflow in `cv::stackBlur` when the kernel size is larger than the image dimensions ### Changes * Added input validation to clamp the kernel size to the image dimensions. * Added a regression test (`regression_28233`) covering 1x1 and small image cases. Fixes #28233 | 10 个月前 | |
Merge pull request #29948 from vrabaud:comma_initializer Remove deprecated CommaInitializer API - #29948 This goes hand in hand with https://github.com/opencv/opencv_contrib/pull/4217 ### 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 | 1 个月前 | |
Merge pull request #30061 from vpisarev:fft_vector vectorized and parallel DFT/DCT + matchTemplate - #30061 (Made with a help from Claude Code Fable 5.1) ## Summary This PR replaces the scalar 1D DFT/DCT kernels in `modules/core/src/dxt.cpp` with a new engine built on universal intrinsics and compiled per ISA through `ocv_add_dispatched_file`, and makes the 2D transforms, the `DFT_ROWS`/`DCT_ROWS` batches and `matchTemplate` (`crossCorr`) multi-threaded. The public API, the output formats (CCS packing of real spectra, `DFT_COMPLEX_OUTPUT` layout, DCT ordering and normalization) and the IPP/OpenCL paths are unchanged. Only floating-point rounding may differ (the new twiddle tables are more accurate than the old recurrence-generated ones, so the error goes down, not up). Measured on Apple M4 Max (16 cores, NEON), macOS 26.5.x, Xcode 26.6, Release build (`-O3`, no IPP). All numbers are the minimum over repeated runs, `5.x` vs this PR. ## Changes ### New 1D engine (`dxt.hpp`, `dxt.simd.hpp`, `dxt.cpp`) - **Split re/im layout.** The input pass gathers the data into separate `re[]`/`im[]` workspace arrays; all middle stages operate on the split arrays, so a complex multiplication is four independent vector FMAs with no lane shuffling. The output pass interleaves back (or packs the CCS / DCT layout) with the scaling fused in. - **Mixed-radix decimation-in-time with a fused first stage.** The plan chooses the first stage (radix 1/2/4/8, twiddle-free, fused with the gather and the digit-reversal permutation) from the power of two in the length, then radix-4 stages, then radix-3, radix-5 and a generic odd radix. There are no radix-2 middle stages. - **Vectorized butterflies with universal intrinsics** (`v_float32`/`v_float64`, VLA-safe): one flat loop per stage with a single clamped counter for both the data and the twiddle offsets (the back-off clamp handles spans that are not multiples of the vector width; such stages run out of place, ping-ponging between two workspace pairs, the others run in place). - **Vectorized first stage.** The radix-2/4/8 first stage reads the input columns contiguously (`v_load_deinterleave`), runs the small DFT in registers and scatters the outputs of every lane with one 4-channel interleaved store. Only odd lengths use a scalar table-driven gather. - **Vectorized edge passes**: interleave/deinterleave, the real-FFT untangling in both directions (with `v_reverse` for the mirrored half), DCT-II post-twiddle and DCT-III pre-twiddle, the Makhoul permutations. - **Inverse = conjugation trick**: the middle stages are direction-free and use forward twiddles only; the inverse conjugates on the gather and negates the imaginary scale on the output. - **Immutable plan + per-executor workspace, zero allocations per transform.** The plan (radix sequence, permutation table, per-stage split twiddle tables) is built once in `init()` and shared by all rows of a batch; every executor owns a workspace. Twiddles are generated in double precision from a two-level exact table (a few ulps, much cheaper to build than the old N-point recurrence, which matters because `cv::dft()` builds a plan on every call). - **Per-ISA dispatch**: `ocv_add_dispatched_file(dxt SSE2 AVX2 AVX512_ICL RVV)`; the kernels are reached through a function-pointer table resolved once per depth, following the pattern of `arithm.simd.hpp` / `warp_kernels.simd.hpp`. The plan is built with the vector width of the dispatched kernels (never with the baseline `VTraits`). - The legacy scalar engine, `DFTInit`, the SSE3 `DFT_VecR*` butterflies and the `noPermute`/ `factors[0] >>= 1` machinery are removed (−1400 lines). The legacy `cv_hal_dft` hook (which took the old tables) is no longer called from the 1D path; the in-tree RISC-V HAL implementation of it will be updated in a separate PR. ### Parallelism - `crossCorr` (`matchTemplate`): the correlation tiles are independent and are now distributed with `parallel_for_`; every worker creates its DFT buffers and `DFT2D` contexts once per range. (The tile loop had been sequential since the C++ rewrite in 2010, which dropped the OpenMP pragma of `icvCrossCorr`.) - 2D DFT/DCT and `DFT_ROWS`/`DCT_ROWS` batches: the row pass, the column pass and the DCT line loop distribute their lines over threads; the 1D plan is shared, each worker allocates its workspace once per range. The number of stripes is derived from the N log N cost, so a 256x256 transform stays on the calling thread and 1024x1024 gets ~20 stripes. Nested calls (the 2D DFTs inside the parallel `crossCorr` tiles) are serialized by `parallel_for_` itself. - The column pass copies columns in batches (`CopyFromColumns`/`CopyToColumns`, 4..16 adjacent columns copied row by row into contiguous buffers sized to stay within 128 KB) instead of two at a time: with power-of-two row steps the old strided copies aliased in the cache and took 60-70% of the 2D time. ### Tests - `Core_DFT.sweep_1d`, `Core_DCT.sweep_1d`: every 5-smooth length up to 2048 plus odd, prime and "awkward" lengths, both depths, C2C forward/inverse, R2C (CCS and complex output), C2R (CCS and complex input), DCT/IDCT, in-place, column vectors, round trips; compared against the naive O(N^2) references of `test_dxt.cpp` with a tolerance of `32*eps*(log2(N) + 2 + maxfactor/16)`. - `Core_DFT.sweep_rows`: `DFT_ROWS` batches sharing one plan. - `Core_DFT.nonzero_rows`: 2D transforms with `nonzero_rows` (previously uncovered). - `Core_DFT.parallel_large`: large 2D / rows / DCT transforms, multi-threaded result vs the single-threaded one. - The naive DCT reference reduces the angle exactly before `cos()` (its accuracy was limiting the comparison for n > 100 in double precision). - Perf: `perf_dft.cpp` gains 1D row/column cases for `dft` and `dct`. - Existing `opencv_test_core` (incl. `Core_DFT*`, `Core_DCT*`, `Core_MulSpectrums`, `Core_DivSpectrums`) and `opencv_test_imgproc` (phaseCorrelate, matchTemplate, filter2D) pass; the x86-64 build (SSE3 baseline + SSE4.1/AVX2/AVX512_ICL dispatch) passes the DFT/DCT tests under Rosetta 2 (AVX2/AVX-512 paths compile-checked only on this machine). ## Performance ### 1D transforms (single row, one thread), microseconds `C2C` = complex-to-complex, `R2C` = real-to-CCS, `C2R` = CCS-to-real (inverse, scaled), `32`/`64` = float/double. | n | C2C32 | C2C64 | R2C32 | C2R32 | R2C64 | DCT32 | IDCT32 | DCT64 | |---|---|---|---|---|---|---|---|---| | 256 | 0.82 → 0.55 | 0.86 → 0.74 | 0.67 → 0.53 | 0.63 → 0.52 | 0.64 → 0.56 | 0.88 → 0.56 | 0.88 → 0.56 | 0.90 → 0.66 | | 1000 | 3.84 → 1.70 | 4.08 → 2.58 | 2.86 → 1.36 | 2.88 → 1.38 | 2.77 → 1.74 | 3.95 → 1.69 | 4.02 → 1.72 | 3.97 → 2.15 | | 1024 | 3.25 → 1.65 | 3.44 → 2.40 | 2.46 → 1.23 | 2.35 → 1.27 | 2.42 → 1.59 | 3.57 → 1.57 | 3.51 → 1.59 | 3.45 → 2.02 | | 4096 | 14.9 → 6.4 | 16.4 → 11.5 | 10.7 → 4.3 | 10.2 → 4.5 | 11.0 → 6.9 | 15.4 → 6.0 | 15.3 → 6.0 | 17.0 → 9.5 | | 4725 (3³·5²·7) | 27.5 → 17.2 | 29.4 → 24.1 | 28.2 → 16.4 | 29.8 → 18.3 | 30.3 → 24.7 | – | – | – | | 65536 | 350 → 273 | 411 → 494 | 223 → 136 | 274 → 139 | 251 → 249 | 318 → 167 | 299 → 159 | 372 → 320 | Each `cv::dft()` call builds its plan anew; at n = 4096 the plan takes ~1.9 µs of the 6.4 µs (the old code spent ~4 µs of 14.9 on its tables). For n = 65536 both versions are bound by the memory traffic of the out-of-cache data, and C2C64 gets slightly slower (the split layout needs one more pass over 1 MB of data; a plan cache or larger radices could recover this later). ### 2D transforms, single thread, microseconds | size | C2C32 | R2C32 | C2R32 | R2C64 | DCT32 | IDCT32 | R2C32 rows | |---|---|---|---|---|---|---|---| | 256×256 | 297 → 140 | 162 → 75 | 165 → 77 | 178 → 126 | 259 → 166 | 290 → 174 | 72 → 29 | | 512×512 | 1660 → 569 | 765 → 306 | 723 → 317 | 896 → 551 | 1381 → 946 | 1377 → 957 | 303 → 125 | | 480×640 | 1555 → 715 | 895 → 377 | 918 → 392 | 978 → 677 | 1248 → 707 | 1262 → 695 | 389 → 147 | | 1024×1024 | 7508 → 2625 | 3781 → 1387 | 3883 → 1398 | 4964 → 3201 | 6438 → 4556 | 6805 → 4583 | 1341 → 516 | | 1080×1920 | 13141 → 5543 | 7143 → 2880 | 7269 → 2970 | 7770 → 5348 | 9735 → 5190 | 9477 → 5381 | 3116 → 1192 | | 2048×2048 | 38151 → 16822 | 18381 → 6973 | 18784 → 7294 | 25146 → 17476 | 30291 → 21631 | 30540 → 22003 | 5809 → 2242 | ### 2D transforms, default thread count (16), microseconds | size | C2C32 | R2C32 | C2R32 | R2C64 | DCT32 | IDCT32 | R2C32 rows | |---|---|---|---|---|---|---|---| | 256×256 | 309 → 138 | 157 → 75 | 161 → 77 | 174 → 126 | 265 → 167 | 293 → 170 | 71 → 29 | | 512×512 | 1660 → 162 | 785 → 155 | 788 → 160 | 866 → 256 | 1410 → 235 | 1366 → 228 | 303 → 41 | | 480×640 | 1531 → 178 | 895 → 142 | 916 → 141 | 957 → 222 | 1241 → 172 | 1248 → 173 | 393 → 46 | | 1024×1024 | 7495 → 381 | 3755 → 274 | 3767 → 269 | 4875 → 478 | 6323 → 650 | 6583 → 630 | 1343 → 94 | | 1080×1920 | 12905 → 681 | 7131 → 403 | 7240 → 382 | 7760 → 657 | 9673 → 605 | 9513 → 607 | 3124 → 143 | | 2048×2048 | 38155 → 1481 | 18324 → 826 | 18559 → 857 | 24861 → 1776 | 30120 → 2592 | 30741 → 2734 | 5890 → 274 | (5.x is single-threaded for all of these; 256×256 stays single-threaded in the new code by design.) ### matchTemplate (`opencv_perf_imgproc`, `*matchTemplate*`), milliseconds Whole suite (156 cases): 921 → 284 ms. Selected cases (8-bit image, 16×16 template unless noted): | image, template | SQDIFF | SQDIFF_NORMED | CCORR | CCORR_NORMED | CCOEFF | CCOEFF_NORMED | |---|---|---|---|---|---|---| | 128×128 | 0.15 → 0.12 | 0.14 → 0.12 | 0.09 → 0.05 | 0.13 → 0.09 | 0.11 → 0.08 | 0.13 → 0.10 | | 320×240 | 0.99 → 0.52 | 1.09 → 0.58 | 0.79 → 0.23 | 0.96 → 0.42 | 0.93 → 0.38 | 1.02 → 0.53 | | 640×480 | 3.19 → 1.17 | 3.35 → 1.22 | 2.27 → 0.29 | 3.12 → 1.04 | 2.94 → 0.90 | 3.43 → 1.38 | | 800×600 | 5.86 → 1.64 | 5.61 → 1.77 | 4.11 → 0.34 | 5.48 → 1.53 | 5.19 → 1.28 | 5.82 → 2.04 | | 1024×768 | 9.73 → 2.72 | 9.59 → 2.90 | 6.88 → 0.48 | 9.11 → 2.45 | 8.44 → 2.05 | 9.84 → 3.44 | | 1280×1024 | 14.92 → 4.33 | 15.01 → 4.58 | 10.70 → 0.64 | 14.31 → 3.97 | 13.40 → 3.33 | 15.37 → 5.58 | | 1280×1024, 1260×1000 | 13.06 → 7.90 | 13.08 → 7.74 | 10.75 → 3.58 | 12.23 → 5.03 | 11.11 → 3.94 | 12.03 → 5.05 | `TM_CCORR` is now dominated by the (still single-threaded) `integral()` and normalization passes in the other methods; those are candidates for a follow-up. ## Notes for reviewers - `modules/core/src/dxt.hpp` documents the engine layout; the plan builder (`DftPlan::build`) and the driver (`runDft`) are in `dxt.cpp`, the kernels in `dxt.simd.hpp`. - Stages whose span is smaller than the vector width run scalar (on NEON this only affects lengths of the form 2·odd; on AVX2/AVX-512 also the first radix-4 stage of 4^k lengths); handling them with narrower fixed-width vectors is a possible follow-up. - A radix-8 middle stage was implemented and measured slower on NEON than two radix-4 stages (register pressure), so it is not included. ### 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 | 12 天前 | |
Merge pull request #29677 from Neal006:imgproc/matchtemplate-bool-mask imgproc: accept CV_Bool masks in matchTemplate (#25895) - #29677 ### Problem `cv::Mat_<bool>::depth()` returns `CV_Bool` in 5.0, where it returned `CV_8U` in 4.x. `matchTemplateMask` gates the mask at `templmatch.cpp:737`, so passing a boolean mask now fails with: ``` (-215:Assertion failed) _mask.depth() == CV_8U || _mask.depth() == CV_32F in function 'cv::matchTemplateMask' ``` A binary mask is a normal input for masked template matching, so this is a regression against 4.x. ### Fix Allow `CV_Bool` in the assertion and widen the mask to `CV_8U` before the existing binarization step. The widening is required rather than passing `CV_Bool` straight through, because `cv::threshold()` does not accept `CV_Bool`. Once widened, the existing `THRESH_BINARY` path treats any non-zero entry as selected, which is exactly the documented `CV_8U` mask semantics. `CV_8U` and `CV_32F` masks take an unchanged path. The masked path is the only one affected: `cv::matchTemplate` routes every non-empty mask through `matchTemplateMask`, and there is no OpenCL mask variant. ### Test `Imgproc_MatchTemplateBoolMask.matches_uchar_mask` compares a `Mat_<bool>` mask against the equivalent `CV_8UC1` mask and requires the results to agree, across all six match methods (`TM_SQDIFF`, `TM_SQDIFF_NORMED`, `TM_CCORR`, `TM_CCORR_NORMED`, `TM_CCOEFF`, `TM_CCOEFF_NORMED`) for `CV_8UC1`, `CV_8UC3` and `CV_32FC1` images. 18 parameter combinations. Verified locally on 5.x: all 18 fail without the source change (with the assertion above) and pass with it. The full `*MatchTemplate*` set, 165 tests, passes. No test data needed, the test 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 #30252 from sshivensolanki:fix-ocl-threshold-depths imgproc: reject unsupported depths in OpenCL threshold - #30252 Fixes #30251 ### Problem `ocl_threshold()` does not check the input depth. On 5.x a `UMat` of depth `CV_64U`, `CV_64S` or `CV_32U` gets through, because `ocl::typeToStr()` maps those depths to valid OpenCL types and the kernel compiles. The function then indexes the 8-entry `min_vals[]` table with a depth of 10, 11 or 12, which reads past the end of the array, and skips the `depth <= CV_32S` flooring of `thresh`. The CPU implementation rejects these depths with `StsUnsupportedFormat`, so the same call throws for a `Mat` and returns an image for a `UMat`, depending on whether an OpenCL device is available. `CV_16BF` and `CV_Bool` did not reach the table, but failed with `Assertion failed (result) in typeToStr` instead of `StsUnsupportedFormat`. ### Fix Return `false` from `ocl_threshold()` for every depth above `CV_64F`, before the kernel is built. Those inputs now fall through to the CPU path, which reports `StsUnsupportedFormat` as it does for `Mat` input. The depths the OpenCL branch accepted in 4.x (`CV_8U` to `CV_64F`) behave as before. ### Tests `Imgproc_Threshold_Unsupported_Depth.umat` is parameterized over `CV_16F`, `CV_16BF`, `CV_Bool`, `CV_64U`, `CV_64S`, `CV_32U` and `THRESH_BINARY`, `THRESH_TRUNC`. It checks that `threshold()` on `Mat` and `UMat`, and `thresholdWithMask()` on `UMat`, throw. On current 5.x with an OpenCL device (Apple M1 Pro, OpenCL 1.2) it fails for `threshold()` on `UMat` with `CV_64U`, `CV_64S` and `CV_32U`. With this patch it passes with OpenCL enabled and with `OPENCV_OPENCL_DEVICE=disabled`. The other `threshold()` tests in `opencv_test_imgproc`, including the OpenCL ones, still pass locally (the `Imgproc_AdaptiveThreshold` tests were not run, they need `opencv_extra` data). ### Pull Request Readiness Checklist See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch - [x] There is a reference to the original bug report and related work - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name. - [ ] The feature is well documented and sample code can be built with the project CMake | 21 天前 | |
Merge pull request #29740 from varun-jaiswal17:imgproc_cleanup 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 | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 19 天前 | ||
| 27 天前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 14 天前 | ||
| 21 天前 | ||
| 4 个月前 | ||
| 2 年前 | ||
| 5 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 个月前 | ||
| 1 个月前 | ||
| 2 年前 | ||
| 10 天前 | ||
| 3 年前 | ||
| 8 年前 | ||
| 14 天前 | ||
| 3 年前 | ||
| 14 天前 | ||
| 2 个月前 | ||
| 11 天前 | ||
| 4 个月前 | ||
| 1 个月前 | ||
| 4 个月前 | ||
| 1 个月前 | ||
| 17 天前 | ||
| 4 个月前 | ||
| 4 年前 | ||
| 1 个月前 | ||
| 2 年前 | ||
| 10 个月前 | ||
| 1 个月前 | ||
| 12 天前 | ||
| 2 个月前 | ||
| 21 天前 | ||
| 2 个月前 |