Added harfbuzz; use it instead of STB to render text #29300
Merge with https://github.com/opencv/opencv_extra/pull/1378.
This is the next big step to improve font rendering in OpenCV 5.x. See #18760, #26301. See also OpenCV 5.0 release notes, where it was pointed out that complex scripts are not rendered correctly, and HarfBuzz integration is needed to fix it. So, here it is — HarfBuzz integration:
* Removed tweaked STB engine. STB truetype rendering engine was included into OpenCV 5.0-pre/5.0 and it was extended to instantiate and render variable fonts, but the support was incomplete and immature.
* Instead, we now use [HarfBuzz](https://github.com/harfbuzz/harfbuzz) — famous font shaping library and now also font rendering library, used by many big companies and organizations.
* As a result, we now correctly render complex scripts, such as arabic or devanagari, correctly handle font ligatures (ff, fi, ft etc.)
<img width="1300" height="600" alt="text_test" src="https://github.com/user-attachments/assets/a7d2c754-0fcf-40f8-8104-578f3a14850b" />
* Potentially, we could also support color emoji, but that would be a next step.
* As with STB-based engine, glyphs are cached (the same glyph from the same font is not rendered twice), so the performance should be on par with the previous engine.
* When OpenCV is built with `-DWITH_HARFBUZZ=ON`, which is set by default, it tries to detect HarfBuzz in the system and use it. If it's not detected, OpenCV builds our own small subset of HarfBuzz.
The following table compares size of libopencv_imgproc.dylib.5.0.0 (Release mode) in different configurations:
| Configuration | libopencv_imgproc (stripped) | delta vs 5.0 |
|----------------------------------------|------------------------------|----------|
| imgproc without text rendering (`-DWITH_HARFBUZZ=OFF`) | 4.27 MB | −2.35 MB |
| imgproc with stb-based engine (5.0) | 6.62 MB | 0.0 Mb |
| imgproc with HarfBuzz-based engine (this PR) | 7.07 MB | +0.45 MB |
The biggest source of the size increase when OpenCV is built with text rendering support (STB- or Harfbuzz-based) is that imgproc in this case includes .ttf fonts (Rubik and 'Wen Quan Yi Micro Hei'), which are gzip-compressed, but still have noticeable size, especially 'Wen Quan Yi' (~2Mb). HarfBuzz itself, compared to STB engine, adds just 0.45Mb, or ~7% to imgproc size. On other platforms (Linux x64, Windows), where IPP or other acceleration libraries are linked into libopencv_imgproc, the harfbuzz footprint is even less noticeable.
### 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
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
Test: Add regression test for LINE_4 vs LINE_8 connectivity #28120
Add test to verify correct behavior of LINE_4 (4-connected) and LINE_8 (8-connected) line drawing. This test ensures:
- LINE_4 produces staircase pattern (more pixels) for diagonal lines
- LINE_8 produces diagonal steps (fewer pixels)
- LINE_4 pixels have only horizontal/vertical neighbors (no diagonal-only)
Regression test for issue #26413 where LINE_4 and LINE_8 behaviors were swapped.
Try to fix distant points to save time when ThickLine() calls FillConvexPoly() #27366
Proposal for #27365
cv::clipLine() is useful, but one should take care of a margin to preserve line caps.
### 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
Fix typos #27338
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
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.
imgproc: C-API cleanup, drawContours refactor #25564
Changes:
* moved several macros from types_c.h to cvdef.h (assuming we will continue using them)
* removed some cases of C-API usage in _imgproc_ module (`CV_TERMCRIT_*` and `CV_CMP_*`)
* refactored `drawContours` to use C++ API instead of calling `cvDrawContours` + test for filled contours with holes (case with non-filled contours is simpler and is covered in some other tests)
#### Note:
There is one case where old drawContours behavior doesn't match the new one - when `contourIdx == -1` (means "draw all contours") and `maxLevel == 0` (means draw only selected contours, but not what is inside).
From the docs:
> **contourIdx** Parameter indicating a contour to draw. If it is negative, all the contours are drawn.
> **maxLevel** Maximal level for drawn contours. If it is 0, only the specified contour is drawn. If it is 1, the function draws the contour(s) and all the nested contours. If it is 2, the function draws the contours, all the nested contours, all the nested-to-nested contours, and so on. This parameter is only taken into account when there is hierarchy available.
Old behavior - only one first contour is drawn:
a
New behavior (also expected by the test) - all contours are drawn:
Fix harmless ASAN error. #24042
For an empty radius, &v[0] would be accessed (though the called functions would not use it due to v.size() being 0). Also add checks for emptyness and fix the first element checks, in case we get INT_MAX to compare to.
### 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
* LineVirtualIterator
Proposal of LineVirtualIterator, an alternative to "LineIterator not attached to any mat".
This is basically the same implementation, replacing the address difference by a single "offset" variable. elemsize becomes irrelevant and considered to be 1. "step" is thus equal to size.width since no stride is expected.
* Update drawing.cpp
fixed warning
* improvement of LineVirtualIterator
instead of being too conservative, the new implementation gets rid of "offset/step" and only keeps a "Point currentPos" up to date.
left_to_right is renamed to forceLeftToRight as suggested (even for the old LineIterator)
assert() replaced by CV_Assert() (even for the old LineIterator)
* fixed implementation
+fixed last commit so that LineVirtualIterator gives at least the same results as LineIterator
+added a new constructor that does not require any Size, so that no clipping is done and iteration occurs from pt1 to pt2. This is done by adding a spatial offset to pt1 and pt2 so that the same implementation is used, the size being in that case the spatial size between pt1 and pt2
* Update imgproc.hpp
fixed warnings
* Update drawing.cpp
fixed whitespace
* Update drawing.cpp
trailing whitespace
* Update imgproc.hpp
+added a new constructor that takes a Rect rather than a Size. It computes the line pt1->pt2 that clips that rect.
Yet again, this is still based on the same implementation, thanks to the Size and the currentPosOffset that can artifically consider the origin of the rect at (0,0)
* revert changes
revert changes on original LineIterator implementation, that will be superseded by the new LineVirtualIterator anyway
* added test of LineVirtualIterator
* More tests
* refactoring
Use C++11 chained constructors
Improved code style
* improve test
Added offset as random test data.
* fixed order of initialization
* merged LineIterator and VirtualLineIterator
* merged LineIterator & VirtualLineIterator
* merged LineIterator & VirtualLineIterator
* merged LineIterator & VirtualLineIterator
* made LineIterator::operator ++() more efficient
added one perfectly predictable check; in theory, since ptmode is set in the end of the constructor in the header file, the compiler can figure out that it's always true/false and eliminate the check from the inline `LineIterator::operator++()` completely
* optimized Line() function
in the most common case (CV_8UC3) eliminated the check from the loop
Co-authored-by: Vadim Pisarevsky <vadim.pisarevsky@gmail.com>
- removed tr1 usage (dropped in C++17)
- moved includes of vector/map/iostream/limits into ts.hpp
- require opencv_test + anonymous namespace (added compile check)
- fixed norm() usage (must be from cvtest::norm for checks) and other conflict functions
- added missing license headers
Vadim Pisarevsky
Alexander Smorkalov
Alexander Smorkalov
Vincent Rabaud
Ghazi-raad
Pierre Chatelier
omahs
inayd
Maksim Shabunin
Alexander Smorkalov
Vincent Rabaud
Alexander Alekhin
Berke
Suleyman TURKMEN
Alexander Alekhin
Aditya Rohan
Vitaly Tuzov