Use validBitIdThreshold for Aruco refineDetectedMarkers #29252
The goal of this PR is to solve the issue raised by @vrabaud in https://github.com/opencv/opencv/pull/28289 (comment: https://github.com/opencv/opencv/pull/28289#discussion_r3355812646).
**Issue:**
`refineDetectedMarkers()` converted the extracted cell ratios with `convertTo(CV_8UC1)` (an implicit 0.5 threshold) before computing the code distance, ignoring `detectorParams.validBitIdThreshold`.
**Solution:**
Make the refine path consistent with the main detection path `Dictionary::identify`.
**Changes:**
- Add a `Dictionary::getDistanceToId()` overload that takes the float cell pixel ratio matrix and `validBitIdThreshold` (similar to how it's done for the `identify()` overload.
- Move the per cell distance computation into a private `getDistanceToIdImpl` helper used by both `identify()` and the new overload of `getDistanceToId()` to avoid repetitions.
- `refineDetectedMarkers()` now calls the new overload.
**Tests:**
- `CV_ArucoRefine.validBitIdThreshold`: a marker with one degraded cell is recovered at threshold 0.7 but not at 0.49.
- `CV_ArucoDictionary.getDistanceToIdCellPixelRatio`: unit-tests both `getDistanceToId` overloads.
All passed
bound alphanumeric values in qr decodeAlpha before map lookup #29378
decodeAlpha in the no-quirc QR backend reads alphanumeric symbols from the post-ECC bitstream and indexes a fixed 45-entry map[] with the raw values. The 11-bit pair from next(11) goes up to 2047, so tuple/45 lands on 45 once the pair passes 2024, and the 6-bit trailing char from next(6) goes up to 63, so map[value] runs out to map[63]. A QR whose data codewords carry an alphanumeric segment with one of those out-of-range values reads past the static array, and the stray byte lands in the string returned by detectAndDecode. WITH_QUIRC defaults off, so this is the decoder a stock build runs.
Before, the only guard was on the encode side, which never emits those values, so the decoder trusted the stream and indexed map[] directly. New version checks value range and return empty string for malformed qr codes.
### 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
- [ ] 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
Optimization ArUco: get border errors in one pass for both normal and inverted markers #29329
This PR is a follow up to optimization in https://github.com/opencv/opencv/pull/29267.
## Context:
When detecting inverted markers, we call `_getBorderErrors` twice:
- `int borderErrors = _getBorderErrors(cellPixelRatio, ...);`
- `Mat invCellPixelRatio = 1.f - cellPixelRatio;`
- `int invBError = _getBorderErrors(invCellPixelRatio, ...);`
meaning:
1. Scan border cells once.
2. Allocate a new Mat.
3. Invert the entire `cellPixelRatio` matrix, not just the border.
4. Scan border cells again on the inverted matrix.
5. If inverted marker is better, copy the full inverted matrix back
## Solution
only call `_getBorderErrors` once and compute both
- borderErrors: `cellPixelRatio > validBitIdThreshold`
- invBorderErrors: `1 - cellPixelRatio > validBitIdThreshold`
This saves:
1. full invert into temporary Mat: (`Mat invCellPixelRatio = 1.f - cellPixelRatio;`)
2. scan temporary border: the second `_getBorderErrors`
3. copy temporary Mat back into `cellPixelRatio`: `invCellPixelRatio.copyTo(cellPixelRatio);`
Note that the solution does not implement:
```
if(params.detectInvertedMarker) {
_getBorderErrorsBoth(...);
} else {
borderErrors = _getBorderErrors(...);
}
```
because the extra cost to computing invBorderErrors: `if(1.f - ratio > validBitIdThreshold) invBorderErrors++;` is negligible. this also avoids having to maintain two functions: `_getBorderErrorsBoth` and `_getBorderErrors`
## Tests:
No visible results when testing the full marker detection pipeline because this step is not expensive. There is a roughly 8% noise when re-running the marker detections making it hard to spot small speed diffs.
When testing only this specific step with a float matrix of size: `(markerSize + 2*border)^2` on a AMD Ryzen 7 (8 cores / 16 threads):
- The new code is 30-45× faster at this stage depending on the marker size and whether the candidate was actually an inverted one, saving ~530-580 ns per candidate, mainly because we removed `Mat invCellPixelRatio = 1.f - cellPixelRatio`
- The new code is equivalent when detecting non-inverted markers +/- 3 ns
---
### 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
Fix speed regression in Aruco identify #29267
### 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
Update ArUco doc #28824
See https://github.com/opencv/opencv/pull/28823
Update of the ArUco doc but targeted for OpenCV 4.
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
objdetect(aruco): fix maxCorrectionBits in predefined dictionaries #29034
This PR fixes the bugs in the creation of some dictionaries and standarizes its construction.
## Bugs
1. **DICT_ARUCO_MIP_36h12_DATA** was incorrectly assigned `maxCorrectionBits=12`, which is the intermarker distance. This was causing a high rate of false positives during detection, which is a significant problem.
2. **APRILTAG** dictionaries were incorrectly created with `maxCorrectionBits=0`, making it impossible to do error correction.
## Solution
Given a intermarker distance X, the correct `maxCorrectionBits = X/2 - 1`. Thus, standardize the construction of Dictionaries as such.
objdetect: clear stale outputs in CharucoDetector::detectDiamonds #28818
## Summary
- clear `diamondCorners`/`diamondIds` outputs at the beginning of `CharucoDetector::detectDiamonds`
- prevent stale detections from previous calls when the current call has fewer than 4 markers or finds no diamonds
- add a regression test that pre-fills outputs, calls `detectDiamonds` with 3 markers, and verifies outputs are empty
Fixes#28783.
## Testing
- built `opencv_test_objdetect` locally
- ran `opencv_test_objdetect --gtest_filter=Charuco.detectDiamondsClearsOutputsWithLessThanFourMarkers`
- result: PASS
Identify ArUco markers based on threshold to reduce false positives #28289
**Goal:** parametrize the current marker identification process (pixel-based majority count) to reduce the number of false positives while maintaining high recall. Useful in high risk scenarios in which false positives are not acceptable.
**Context:** This PR builds on top of https://github.com/opencv/opencv/pull/23190 in which we've introduced a pixel-based confidence in the marker detection.
**Solution:** Include a new parameter: `validBitIdThreshold` used to identify markers based on the pixel count of each cell. Set the parameter default either to 50% which is equivalent to the current majority count implementation or to 49% which already singnificantly reduces the number of false positives (see details below).
**Test coverage:**
- Unit tests: `CV_ArucoDetectionThreshold`, `CV_InvertedArucoDetectionThreshold`
- The impact of `validBitIdThreshold` on false positives was also tested using the benchmark dataset: `MIRFLICKR-25k` https://www.kaggle.com/datasets/skfrost19/mirflickr25k which contains random images without any markers. Every marker detection is a false positive.
Example of images in the dataset:
**Results:** A threshold of 49% already allows to significantly reduce the number of false positives for the dict `DICT_4X4_1000`:
- `5942` false positives for `validBitIdThreshold = 0.5`
- `629` false positives for `validBitIdThreshold = 0.49` and `0.46`
- number of false positives divided by `9.5` when compared to `validBitIdThreshold = 0.5`
- `139` false positives for `validBitIdThreshold = 0.43` and `0.4`
- number of false positives divided by `42` when compared to `validBitIdThreshold = 0.5`
Dicts with a higher number of cells are not as impacted since it's much harder to obtain false positives. However, the less cells in a marker the further away it can be reliably detected, so the dict `DICT_4X4_1000` is commonly used.
<img width="1280" height="800" alt="false_positive_image_rate" src="https://github.com/user-attachments/assets/1a0ee16a-221d-443e-835b-022ed6dea6b0" />
In the image attached, the values of `validBitIdThreshold` tested are: `0.10f, 0.20f, 0.30f, 0.40f, 0.43f, 0.46f, 0.49f, 0.50f, 0.53f, 0.56f, 0.60f, 0.70f, 0.80f, 0.90f`
Summary of the results: [summary.csv](https://github.com/user-attachments/files/24315662/summary.csv)
Note that we can also analyse the number of false positives per marker `id`. For example, here's the histogram for the dict `DICT_4X4_1000`. (The CSV attached contains all the results)
<img width="1440" height="640" alt="false_positive_ids_DICT_4X4_1000_thr0 50" src="https://github.com/user-attachments/assets/af4f3ff8-9b8f-4682-9d51-a090c2610d8c" />
For example, the marker id 17 is detected 252 times with `validBitIdThreshold = 0.5` and only 34 times with `validBitIdThreshold = 0.49`. Looking at marker 17 (see below), we understand that this simple pattern randomly occurs in images.
<img width="447" height="441" alt="Marker17" src="https://github.com/user-attachments/assets/f5d09227-b39b-4598-94f9-b529f8300703" />
Results for every dict and every `validBitIdThreshold` [per_id.csv](https://github.com/user-attachments/files/24315667/per_id.csv)
**Missing coverage:** there is no labeled dataset with images containing markers to analyse the impact of on the recall (i.e. look at the true positive rate). For my specific use case (drones) any threshold above `0.4` allows to maintain a high recall in all conditions.
### 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
- [ ] 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
Fix ~0.5px systematic offset in CharucoDetector subpixel refinement #28380Resolves#25539
### Problem
`CharucoDetector::detectBoard` produces Charuco corner coordinates that are consistently offset by approximately **+0.5 pixels** compared to `findChessboardCorners + cornerSubPix`.
This offset is systematic (mean ≈ −0.5 px when comparing legacy − Charuco) and reproducible across images. Visual inspection also shows that the legacy chessboard detector aligns better with the actual corner locations.
### Root cause
In `charuco_detector.cpp`, the points passed to `cornerSubPix` are manually shifted by `-Point2f(0.5f, 0.5f)` before refinement and then shifted back by `+Point2f(0.5f, 0.5f)` after refinement.
However, `cornerSubPix` refines corners in **absolute image coordinates** and converges to the true saddle point based on image gradients. Shifting the initial guess does not affect the converged result as long as the true corner lies within the refinement window.
The additional `+0.5` shift applied after refinement therefore introduces a constant bias, resulting in:
```
P_out = P_true + 0.5
```
### Solution
Remove the manual `±0.5` coordinate shifts around the `cornerSubPix` call and let the refined result be returned directly.
### Test updates
Updated expected corner values in the following tests:
- `testBoardSubpixelCoords`
- `testSeveralBoardsWithCustomIds`
The previous expected values (e.g. `200`, `250`, `300`) were only correct due to the +0.5px bias introduced by the bug.
`generateImage` creates checkerboard squares of exactly **50 pixels**, which places true corner locations on **pixel boundaries** rather than pixel centers. As a result, the correct subpixel coordinates are:
```
199.5, 249.5, 299.5
```
instead of the previously expected integer values.
After updating the expected values, all **30 Charuco-related tests pass** with the fix applied.
### Verification
I verified the fix using a Python reproducer that compares `CharucoDetector` output against `findChessboardCorners + cornerSubPix`:
- **Before fix:** mean error ≈ −0.501 px
- **After fix:** mean error ≈ −0.001 px
After the change, the Charuco detector output aligns with the legacy chessboard detector both numerically and visually.
### Notes
This change only affects the post-refinement coordinate handling and does not alter detection logic, refinement parameters, or performance.
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
docs: fix spelling errors in documentation and code #28301
- [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
- [ ] The feature is well documented and sample code can be built with the project CMake
### Description
Fixed multiple spelling errors across documentation, comments, and code:
- 'colummn' → 'column' (cublas.hpp, 3 occurrences)
- 'points_per_colum' → 'points_per_column' (calib3d.hpp, 3 occurrences)
- 'Asignee' → 'Assignee' (sift files, 2 occurrences)
- 'compability' → 'compatibility' (face.hpp, 2 occurrences)
- 'orignal' → 'original' (aruco_detector.cpp)
- 'refrence' → 'reference' (chessboard.cpp)
- 'indeces' → 'indices' (stitching.hpp)
- 'OutputPrecison' → 'OutputPrecision' (test)
- 'tranform' → 'transform' (slice_layer.cpp, 3 occurrences)
Total: 24 fixes across 14 files. Documentation and comment changes only, no functional impact.
Precompute X values in Forney algorithm to eliminate redundant gfPow calls.
Previously, gfPow(2, ...) was computed multiple times for the same error
location across different loop iterations, resulting in O(L²) redundant
Galois field arithmetic operations.
This change:
- Precomputes all X values once before the main loop
- Reduces complexity from O(L²) to O(L) for X value computations
- Removes the TODO comment at line 1642
- No functional changes, only performance improvement
The optimization is most beneficial when there are many error locations
in QR codes (larger L values).
Include pixel-based confidence in ArUco marker detection #23190
The aim of this pull request is to compute a **pixel-based confidence** of the marker detection. The confidence [0;1] is defined as the percentage of correctly detected pixels, with 1 describing a pixel perfect detection. Currently it is possible to get the normalized Hamming distance between the detected marker and the dictionary ground truth [Dictionary::getDistanceToId()](https://github.com/opencv/opencv/blob/4.x/modules/objdetect/src/aruco/aruco_dictionary.cpp#L114) However, this distance is based on the extracted bits and we lose information in the [majority count step](https://github.com/opencv/opencv/blob/4.x/modules/objdetect/src/aruco/aruco_detector.cpp#L487). For example, even if each cell has 49% incorrect pixels, we still obtain a perfect Hamming distance.
**Implementation tests**: Generate 36 synthetic images containing 4 markers each (with different ids) so a total of 144 markers. Invert a given percentage of pixels in each cell of the marker to simulate uncertain detection. Assuming a perfect detection, define the ground truth uncertainty as the percentage of inverted pixels. The test is passed if `abs(computedConfidece - groundTruthConfidence) < 0.05` where `0.05` accounts for minor detection inaccuracies.
- Performed for both regular and inverted markers
- Included perspective-distorted markers
- Markers in all 4 possible rotations [0, 90, 180, 270]
- Different set of detection params:
- `perspectiveRemovePixelPerCell`
- `perspectiveRemoveIgnoredMarginPerCell`
- `markerBorderBits`
The code properly builds locally and `opencv_test_objdetect` and `opencv_test_core` passed. Please let me know if there are any further modifications needed.
Thanks!
I've also pushed minor unrelated improvement (let me know if you want a separate PR) in the [bit extraction method](https://github.com/opencv/opencv/blob/4.x/modules/objdetect/src/aruco/aruco_detector.cpp#L435). `CV_Assert(perspectiveRemoveIgnoredMarginPerCell <=1)` should be `< 0.5`. Since there are margins on both sides of the cell, the margins must be smaller than half of the cell. When setting `perspectiveRemoveIgnoredMarginPerCell >= 0.5`, `opencv_test_objdetect` fails. Note: 0.499 is ok because `int()` will floor the result, thus `cellMarginPixels = int(cellMarginRate * cellSize)` will be smaller than `cellSize / 2`
### 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
- [ ] 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.
- [x] The PR is proposed to the proper branch
- [x] The feature is well documented and sample code can be built with the project CMake
Replaces wasteful temporary object construction with in-place construction using emplace_back. Covers hot paths in objdetect, imgproc, and stitching modules.
Fixed issues identified by PVS Studio #28185
Partially fixes https://github.com/opencv/opencv/issues/28167
Paper: https://pvs-studio.com/en/blog/posts/cpp/1321/
Closed items: N2, N4, N5, N6, N7, N8, N10, N11, N13, N14.
To be continued...
### 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
Remove floating point arithmetic from angle computation in QR codes #28157
### Pull Request Readiness Checklist
resolves https://github.com/opencv/opencv/issues/24646
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.
- [x] The feature is well documented and sample code can be built with the project CMake
Fix QRCodeDetector::detectAndDecode crash #27877
### Pull Request Readiness Checklist
Fix#27807
The problem is that when we find closest points from hull, we can get same closest point for several different points
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
doc: fix doxygen warnings for imgcodecs, flann and objdetect #27730
Close https://github.com/opencv/opencv/issues/27729
### 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
Consider QRCode ECI encoding #24426
### Pull Request Readiness Checklist
related: https://github.com/opencv/opencv/pull/24350#pullrequestreview-1661658421
1. Add `getEncoding` method to obtain ECI number
2. Add `detectAndDecodeBytes`, `decodeBytes`, `decodeBytesMulti`, `detectAndDecodeBytesMulti` methods in Python (return `bytes`) and Java (return `byte[]`)
3. Allow Python bytes to std::string conversion in general and add `encode(byte[] encoded_info, Mat qrcode)` in Java
Python example with Kanji encoding:
```python
img = cv.imread("test.png")
detect = cv.QRCodeDetector()
data, points, straight_qrcode = detect.detectAndDecodeBytes(img)
print(data)
print(detect.getEncoding(), cv.QRCodeEncoder_ECI_SHIFT_JIS)
print(data.decode("shift-jis"))
```
```
b'\x82\xb1\x82\xf1\x82\xc9\x82\xbf\x82\xcd\x90\xa2\x8aE'
20 20
こんにちは世界
```
source: https://github.com/opencv/opencv/blob/ba4d6c859d21536f84e0328c16f4cc3e96bf3065/modules/objdetect/test/test_qrcode_encode.cpp#L332
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
Explicitly specify enum type scopes to improve Java wrapper generation #27228
Changed DataLayout and ImagePaddingMode to dnn::DataLayout and dnn::ImagePaddingMode to explicitly specify their scopes. This allows gen_java.py to correctly register disc_type, preventing constructors and methods using these enum types from being skipped during Java wrapper generation.
Similarly updated QRCodeEncoder::CorrectionLevel and QRCodeEncoder::EncodeMode with explicit scope declarations.
Also added a new Java test class `DnnBlobFromImageWithParamsTest` based on: https://github.com/opencv/opencv/blob/4.x/modules/dnn/test/test_misc.cpp#L133-L243
Related issues
#23753
### 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 QR code encoder with autoversion #27244
The autodetected version is not honored in the `QRCodeEncoderImpl::encode*` methods. This fixes#27183
### 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
Add test for ArucoDetector::detectMarkers #27079
### Pull Request Readiness Checklist
Related to #26968 and #26922
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
Fix Aruco marker incorrect detection near image edge #26968
### Pull Request Readiness Checklist
Fix#26922
As I understood the algorithm, at the first stage we search for the contours of the marker several times (adaptive threshold with different windows sizes). Therefore, for the same marker, we get several contours (inner and outer with different sizes due to the different windows sizes). In the second stage, we group the contours for the same marker into one group, from which we take the largest contour as the best candidate (which should best match the border of the marker).
The problem is that using the `minDistanceToBorder` parameter, we discard contours at the first stage. Thus, we discard the best candidates most appropriate to the marker border, and inner contours may remain, representing a significantly smaller marker border (which we observe in the issue).
But if we use the `minDistanceToBorder` parameter to discard the best candidate of the group at the second stage, then there will be no such problems and we will completely discard markers located too close to the border of the image.
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.
- [x] The feature is well documented and sample code can be built with the project CMake
Use map to manage unique marker size candidate trees.
Avoid code duplication.
Add a test to show double detection with overlapping dictionaries.
Generalize to marker sizes of not only predefined dictionaries.
Uwez Khan
Jonas Perolini
uwezkhan
Alexander Smorkalov
Vincent Rabaud
s-trinh
Rafael Muñoz Salinas
Kumataro
Jeevan Mohan Pawar
Murat Raimbekov
Alexander Smorkalov
Siddharth Panditrao
Abhishek
Adrian Kretz
AdwaithBatchu
Dmitry Kurtaev
Maxim Smolskiy
Muhammed Jaseem Pallikkal
Marius Wachtler
kallaballa
Sergei Nikiforov
utibenkei
Benjamin Knecht