| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
imgproc: add RGB <-> Oklab color conversion Adds COLOR_BGR2Oklab, COLOR_RGB2Oklab, COLOR_Oklab2BGR, and COLOR_Oklab2RGB to cvtColor, implementing Bjorn Ottosson's Oklab perceptual color space (https://bottosson.github.io/posts/oklab/), requested in #21760. Scope for this first PR: CV_8U and CV_32F only (matching the existing Lab/Luv precedent -- neither supports CV_16U either, likely for the same reason: the cube-root nonlinearity doesn't lend itself to a fixed-point integer fast path), plain scalar C++ (no SIMD, no OpenCL kernel -- cvtColor's CV_OCL_RUN/CV_Assert machinery already falls back to this CPU path cleanly for codes without an OpenCL case), and the core RGB<->Oklab conversion only (not the Okhsv/Okhsl variants the issue also mentions, which the issue itself calls secondary to the "most directly important" Oklab conversion). Encoding: CV_32F keeps Oklab's native range (L in [0,1], a/b roughly in [-0.5,0.5] for in-gamut sRGB colors), matching how the reference formulas and other tools (e.g. CSS Color 4's oklab()) represent it. CV_8U scales L by 255 and offsets a/b by 128, mirroring CIE Lab's own 8-bit encoding shape. Testing: - The forward matrices were verified against an independent NumPy reimplementation before writing any C++: round-trip identity over 20000 random RGB samples (~1.6e-6 max error), plus cross-checked pure red/green/blue/white/black/gray against commonly-published Oklab reference values -- matches to 6+ significant figures. - New tests in test_color.cpp: reference-value cross-check (same known values as above, now through the actual cv::cvtColor), a channel-order check (COLOR_RGB2Oklab vs COLOR_BGR2Oklab on the same logical pixels), float32 and uint8 round-trips, and alpha-channel passthrough on the 4-channel inverse. All pass; verified the uint8 round-trip test actually exercises meaningful precision by comparing its tolerance against CIE Lab's own established uint8 tolerance (CV_ColorLabTest accepts up to 37 for the analogous case; this uses 32 for a still-meaningful, not looser, bound). - Confirmed swapBlue() needed COLOR_BGR2Oklab/COLOR_Oklab2BGR added to its explicit list -- its default (true) is correct for the RGB variants by accident but wrong for the BGR ones, which would have silently swapped red and blue. Caught by code review before testing, then confirmed fixed via the channel-order test. - Ran the full opencv_test_imgproc suite: no new failures (the same 360 pre-existing "missing opencv_extra test data" failures present before this change, e.g. StackBlur/HoughCircles/ColorBayer, all in unrelated files). - Verified the UMat (OpenCL) path falls back to the CPU implementation correctly (no OpenCL kernel is added in this PR). - Added a perf test (cvtColorOklab) covering both directions, CV_8U and CV_32F, at VGA/720p/1080p. Natural follow-ups, intentionally left out of this first PR: SIMD/ fixed-point optimization (this is a plain scalar implementation), Okhsv/Okhsl, and an OpenCL kernel. | 1 个月前 | |
1. updated Rubik font: 1) numerals are now monospace, e.g. '1' has the same width as '0', 2) '0' is different from capital 'o', 3) new glyphs added 2. stb_truetype upgraded from 1.24 to 1.26 with some fixes in rendering. | 2 年前 | |
Clarify Canny L2gradient threshold comparison in doc comment Signed-off-by: NUAAwqy <146524024+NUAAwqy@users.noreply.github.com> | 16 天前 | |
imgproc: reject N-D input in remap, warpAffine and warpPerspective N-D Mats (e.g. NHWC batches from Python) were silently processed as a garbage 2D image by remap() and warpPerspective(). Check src dims up front and raise a descriptive error instead. Fixes #29589 | 26 天前 | |
imgproc: parallelize cv::pyrMeanShiftFiltering's per-row loop | 11 天前 | |
Merge pull request #30407 from asmorkalov:as/ocl_fp64 Fixed FP64 build in matchTemplate kernel | 9 天前 | |
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 | 9 天前 | |
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 个月前 |