| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Merge pull request #30174 from SavyaSanchi-Sharma:doc/fisheye calib: fix fisheye and calibration documentation | 3 天前 | |
Merge pull request #29965 from pranayr710/fix/convert-64bit-saturation core: saturate when narrowing 64-bit and 32U sources in convertTo | 2 天前 | |
Merge pull request #30193 from Prasadayus/dnn-fastgemm1t-neon-5x dnn: unroll NEON fastGEMM1T to 8 outputs | 2 天前 | |
Merge pull request #29392 from YangGuanyuhan/ai-disk-lightglue-pipeline [GSOC] feat: Add DISK LightGlue matcher and fix DNN finalizeLayers state leak | 3 天前 | |
Remove references to C++ < 17 and older compiler versions. According to https://github.com/opencv/opencv/wiki/OpenCV-4-to-5-migration#1-build-requirements are not supported: - GCC < 7 - clang < 9 - MSVC < 2017 (19.14) | 17 天前 | |
Merge pull request #30174 from SavyaSanchi-Sharma:doc/fisheye calib: fix fisheye and calibration documentation | 3 天前 | |
Enable -Wimplicit-fallthrough | 18 天前 | |
fix the RGB row copy in tiff readData | 9 天前 | |
Merge pull request #30187 from Prasadayus/imgproc-laplacian-simd-5x imgproc: vectorize <CV_32S, CV_16S> column filter | 2 天前 | |
Merge pull request #29755 from aditya2907:feature_enhancements 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. | 1 个月前 | |
Merge branch 4.x | 3 个月前 | |
Merge branch 4.x | 3 个月前 | |
Merge pull request #29262 from Haris-bin-shakeel:fix-objc-volumetype-5x objc: Fix VolumeType enum name clash on MacOS #29262 ### Pull Request Readiness Checklist - [x] I agree to contribute to the project under Apache 2 License. - [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV - [x] The PR is proposed to the proper branch - [x] There is a reference to the original bug report and related work - [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable - [ ] The feature is well documented and sample code can be built with the project CMake **Problem** When the ObjC wrapper is generated, the global enum `cv::VolumeType` from the ptcloud module is emitted as `typedef NS_ENUM(int, VolumeType)`. macOS defines `typedef OSType VolumeType` in CoreServices, which leads to a typedef-redefinition error during the framework build. **Fix** `add_enum()` in `gen_objc.py` now handles namespace-global enums by falling back to a module-level lookup (`self.Module`) when the enum has no enclosing class. A new `gen_dict.json` entry maps `VolumeType` -> `PtcloudVolumeType`, and the import generation automatically uses the renamed enum. Fixes #29260 | 3 个月前 | |
Merge pull request #30123 from Rishiii57:fix-qr-mode-and-unicode-30110 objdetect: handle unsupported QR modes gracefully - #30123 ### 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 ### Description Resolves #30110. This PR addresses two related defects in `QRCodeDetector` and Python string conversion bindings: 1. **`objdetect`**: In `QRCodeDecoderImpl::decodeSymbols` (`qrcode_encoder.cpp`), encountering unsupported or unhandled QR mode indicators (such as Hanzi mode 13 or FNC1) previously called `CV_Error(Error::StsNotImplemented, format("mode %d", currMode))`, throwing an unhandled `cv2.error` exception out of high-level detector calls like `detectAndDecodeMulti()`. Replaced `CV_Error` with `return false;` to report symbol decode failure gracefully. 2. **`python`**: In `pyopencv_from(const String& value)` (`cv2_convert.cpp`), converting C++ string payloads to Python `str` previously called `PyString_FromString` (`PyUnicode_FromString`), which raises a `UnicodeDecodeError` when decoding non-UTF-8 payload bytes (e.g. GB2312 or Shift-JIS lead bytes). Updated string conversion to use `PyUnicode_DecodeUTF8(..., "surrogateescape")` with fallback to `PyBytes_FromStringAndSize`. ### Testing - Added `TEST(Objdetect_QRCode, unsupported_mode_graceful)` in `modules/objdetect/test/test_qrcode.cpp`. | 3 天前 | |
core: add ArmPL HAL backend for cv::SVD::compute | 12 天前 | |
Merge pull request #30007 from vpisarev:fix_flt2int core: saturating float/double->intXY conversions in cvRound/cvFloor/cvCeil and the corresponding univ. intrinsics. - #30007 Merge pull request #30007 from vpisarev:fix_flt2int Fixes #28557 (supersedes the tail-only fix from #29895). ### The problem On x86 `cvtss2si`/`cvtsd2si`/`cvtps2dq` return the "integer indefinite" value `0x80000000` (`INT_MIN`) for any out-of-range input, so ```cpp cvRound(3e9); // INT_MIN saturate_cast<ushort>(60000.f*60000.f); // 0 instead of 65535 (#28557: the scalar tail of cv::multiply) v_round(v_float32(1e10f)); // INT_MIN lanes ``` The problem is not x86-only. `cvRound()` on aarch64, riscv64 and loongarch64 went through `(int)lrint()`, which the compilers implement as a 64-bit conversion followed by truncation to 32 bits, i.e. large values *wrap* instead of saturating (`fcvtzs x0` + `mov w0`, `fcvt.l.d` + `sext.w`). NEON `v_round/v_floor/v_ceil/v_trunc(v_float64x2)` narrowed with a wrapping `vmovn`, and `saturate_cast<unsigned/int64/uint64>(float/double)` were plain UB above the target range. ### The fix **`fast_math.hpp`** - `cvRound()`, `cvFloor()`, `cvCeil()` saturate on every platform. New `cvTrunc()` (round towards zero, saturating; the scalar counterpart of `v_trunc`) and `cvRound64()` (round-half-to-even to `int64`, saturating). - x86 (SSE2): the input is clamped from above (`min`) before `cvt*`; the "indefinite" value is already the correct result below `INT_MIN`. `cvFloor` also clamps from below because of the "-1" correction. - aarch64 (`__GNUC__`/clang): one-instruction inline asm `fcvtns/fcvtms/fcvtps/fcvtzs` (GCC's `arm_neon.h` has no scalar f64→s32 ACLE functions, and inline asm needs no header). - riscv64: `fcvt.w.{s,d}` / `fcvt.l.{s,d}` with an explicit rounding mode (`rne`, `rdn`, `rup`, `rtz`). - loongarch64: `ftint*.w.{s,d}` + `movfr2gr.s` (the old `.l.d` + `movfr2gr.d` wrapped); `cvRound` got a branch too. - MSVC ARM64: the 64-bit results are clamped before narrowing. - Portable `#else` branch: hand-written clamp before the conversion, no new headers. - Exact semantics: `double` saturates to `INT_MIN`/`INT_MAX` exactly. `INT_MAX` is not representable as `float`, so `float` inputs `>= 2^31` give **2147483520** (the largest float below 2^31, the clamp value) where the instruction does not saturate by itself (x86, portable) and `INT_MAX` where it does (ARM, RISC-V, LoongArch). Both are accepted by the tests and documented. - **NaN handling is out of scope in this PR**. **`saturate.hpp`** - `float/double → unsigned/int64/uint64` now saturate and use round-half-to-even via `cvRound64()` (no libm `round()` call; OpenCV builds without `-ffast-math`, where `rint()`/`round()` are real calls). - `int/int64 → schar/short/int` range checks are done in unsigned arithmetic. The old `(unsigned)(v - SHRT_MIN)` overflowed (UB) for `v > INT_MAX - 32768`; such values were unreachable before but are returned by the saturating `cvRound()` now, and GCC 15 actually exploits the UB (derives `v <= INT_MAX-32768` and folds neighbouring comparisons). **Universal intrinsics** - SSE, AVX2, AVX-512: clamp before `cvt` in `v_round/v_floor/v_ceil/v_trunc` (f32 and f64, `v_round(a, b)` included). AVX2 keeps `_mm256_floor_ps/_ceil_ps`. - NEON f64: saturating narrow (`vqmovn_s64`); `v_floor/v_ceil` use `fcvtms/fcvtps` directly; `v_trunc` used `vcvtaq` (round-to-nearest-away) instead of truncation. - WASM f32: clamp before the `-1/+1` corrections (they wrapped `INT_MIN`); `v_round` was `trunc_sat(a + 0.5)` (wrong for negatives and ties), now `f32x4.nearest`; f64 `v_trunc` via `cvTrunc`. - MSA f64: clamp before `pckev.w`, which takes the low 32 bits of the saturated int64. - RVV f16 `v_floor`: rounding mode `2` (RDN) instead of `1` (RTZ). - VSX, LSX/LASX, RVV f32/f64, RVV 0.7.1: untouched, the conversion instructions saturate by ISA definition. - `intrin_cpp.hpp`: `v_trunc` via `cvTrunc`; docs mention the saturation. `arithm.simd.hpp` is not modified: `Core_Arithm.mul_overflow_28557` passes because the scalar tail's `saturate_cast<ushort>(float)` saturates now. ### Tests - `Core_Arithm.mul_overflow_28557` re-enabled. - `Core_Arithm.mul_overflow_tail_and_inplace`: 8U/8S/16U/16S, row lengths 1..70 (vector body + scalar tail), out-of-place and in-place `multiply`, `mul`, `pow(x, 2)`. - `Core_ConvertTo.float_overflow_saturation`: 32F/64F → 8U/8S/16U/16S/32S/32U/64S/64U with `±1e10`, `±1e30`, `±inf`, `2147483647.5`, `x.5` etc.; vector body vs. scalar reference, extreme inputs must hit the type limits. - `Core_FastMath.SaturatingRoundingOps`: boundary table (`2147483647.5`, `-2147483648.5`, `2147483520f`, `-2147483904f`, `±DBL_MAX`, `±inf`, ...) plus a 200k-value log-uniform random sweep against `nearbyint/floor/ceil/trunc` clamped to `int`. - `Core_FastMath.Round64`: boundaries around `±2^63`, `.5` cases, random sweep. - `Core_SaturateCast.FloatToIntSaturation`, `RoundHalfToEven`, `IntToNarrowerIntBoundaries` (regression for the signed-overflow UB). - `test_intrin_utils.hpp` (`test_float_math`, `test_round_pair_f64`): overflow/boundary lanes for f32, f64 and f16, compared against the scalar functions and checked against explicit `INT_MIN` / `[2147483520, INT_MAX]` / `INT_MAX` limits. Runs on every backend and dispatch level. ### Verification - x86-64, GCC 15.2, `CPU_BASELINE=SSE4_2 CPU_DISPATCH=AVX2,AVX512_SKX`: full `opencv_test_core` passes (16864 tests), i.e. SSE4.2 baseline, AVX2 dispatch and the CPP emulator paths. AVX-512 is compile-checked only (no AVX-512 hardware here). - The standalone scalar checks also pass with the portable `#else` branch forced (`-U__SSE2__`) and under `-fsanitize=undefined`. - aarch64 (`aarch64-linux-gnu-gcc-14`) and riscv64 (`riscv64-linux-gnu-gcc-14 -march=rv64gcv_zvfh`): compile-checked, generated code inspected (`fcvtns w0, d0`, `fcvt.w.d a0, fa0, rne`, `sqxtn`, `vfcvt.x.f.v`, ...). Not run (no hardware/qemu). - **Not verified at all** (please watch CI): LoongArch (`ftint*.w.d`/`ftintrne.*` asm), WASM (`wasm_f32x4_nearest`), MSA, MSVC ARM64 (`vcvtd_s64_f64`, `vcvts_s32_f32`, `vcvtnd_s64_f64`). ### Behaviour changes worth noting - `saturate_cast<unsigned/int64/uint64>(x.5)` now rounds half to even (was half away from zero), consistent with all the other integer targets. - `cvRound(float)` for inputs `>= 2^31` returns **2147483520** on x86 (was `INT_MIN`); `INT_MAX` on ARM/RISC-V. It would be noticeably slower to implement true saturation to `INT_MAX`. Note that around `INT_MAX` float's cannot represent the integer's exactly anyway. - `saturate_cast<int>(1e10)` is `INT_MAX` (documentation used to say "no clipping is done for 32-bit integers"). ### 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 code under GPL or another license incompatible with OpenCV. - [x] The PR is proposed to the proper branch (`5.x`). - [x] There is a reference to the original bug report and related work: #28557, #29895. - [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable: accuracy tests added, no test data needed. - [x] The feature is well documented and sample code can be built with the project CMake: doxygen comments of `cvRound`/`cvFloor`/`cvCeil`/`cvTrunc`/`cvRound64`, `saturate_cast` and the intrinsics conversion group updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01KVnDjvrFtxcyw7RFzSPews | 11 天前 | |
Merge pull request #30173 from SavyaSanchi-Sharma:calib/fisheye Calib: assersion fix of fisheye calib - #30173 Replaces a CV_Assert in fisheye::InitExtrinsics with a graceful failure path (returns bool, caller now throws a descriptive StsBadArg naming the degenerate view) instead of crashing on a hard assert. Also adds validation that rejects legacy numeric flag values passed to fisheye::calibrate/stereoCalibrate, and fixes CALIB_CHECK_COND to actually gate the condition check in stereo calibration. Includes an hdr_parser.py change to resolve using Base::CONST enum aliases for Python bindings. ### 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 | 3 天前 | |
Remove now unused GET_OPTIMIZED | 18 天前 | |
Merge pull request #29392 from YangGuanyuhan/ai-disk-lightglue-pipeline [GSOC] feat: Add DISK LightGlue matcher and fix DNN finalizeLayers state leak | 3 天前 | |
Remove references to C++ < 17 and older compiler versions. According to https://github.com/opencv/opencv/wiki/OpenCV-4-to-5-migration#1-build-requirements are not supported: - GCC < 7 - clang < 9 - MSVC < 2017 (19.14) | 17 天前 | |
Merge pull request #29989 from vrabaud:variant Add compile-time fast paths for _InputArray/_OutputArray | 2 天前 | |
videoio(ffmpeg): keep frame properties across av_hwframe_transfer_data() With hardware decoding, retrieveFrame() downloads the GPU frame into a new AVFrame with av_hwframe_transfer_data(). That call copies the pixel data only: colorspace, color_range, color_primaries, color_trc and chroma_location are left unspecified in the system memory copy. With swscale >= 8.12.100 the color conversion goes through sws_scale_frame(), which configures itself from the properties of the source frame. Given unspecified properties it falls back to BT.601 limited range, so hardware-decoded frames are converted with the wrong matrix whatever the stream signals, and full range streams additionally lose contrast. Software decoding is not affected, the decoder output carries the properties. fftools/ffmpeg_dec.c handles this by calling av_frame_copy_props() right after the transfer; do the same. A failure is only logged: it can only be an allocation failure on side data, and the picture itself is still valid. With swscale < 8.12.100 the conversion context is initialized without the frame properties, so this change has no effect on that path. Measured on Windows x64 with the OpenCV 5.0.0 FFmpeg wrapper built by the opencv_3rdparty MinGW recipe against FFmpeg n8.1.3 (libswscale 9.5.103), D3D11VA decoding, on two synthetic BT.709 H.264 samples: ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30 -t 2 -c:v libx264 \ -pix_fmt yuv420p -color_range tv -colorspace bt709 \ -color_primaries bt709 -color_trc bt709 bt709_tv.mp4 ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30 -t 2 -c:v libx264 \ -pix_fmt yuvj420p -color_range pc -colorspace bt709 \ -color_primaries bt709 -color_trc bt709 bt709_pc.mp4 Frame 0 is compared with a reference built from the same static FFmpeg libraries: software decode, lossless repack to NV12 (the D3D11VA download format), av_frame_copy_props(), then sws_scale_frame() to BGR24 exactly as retrieveFrame() does. sample before (mean / max abs diff) after bt709_tv.mp4 7.424 / 94 bit-exact bt709_pc.mp4 3.286 / 101 bit-exact Before the patch the output is bit-exact with the same reference built without the frame properties, which confirms the cause. Software decoding output is unchanged (bit-exact before and after). Two real H.264 recordings (BT.709, full and limited range) behave the same way. Hardware and software decoding still do not produce identical pictures after this patch: swscale converts NV12 and yuv420p differently around sharp chroma edges. That difference exists with the same properties outside OpenCV too and is not addressed here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 10 天前 | |
Update CMakeLists.txt | 1 个月前 | |
Merge pull request #26405 from kaingwade:rename_features2d Rename features2d #26405 This PR renames the module _features2d_ to _features_ as one of the Big OpenCV Cleanup #25007. Related PR: opencv/opencv_contrib: [#3820](https://github.com/opencv/opencv_contrib/pull/3820) opencv/ci-gha-workflow: [#192](https://github.com/opencv/ci-gha-workflow/pull/192) | 1 年前 |