Identify ArUco markers based on threshold to reduce false positives#28289
Identify ArUco markers based on threshold to reduce false positives#28289asmorkalov merged 12 commits intoopencv:4.xfrom
Conversation
|
Mac OS ARM: |
|
Thank you for the heads up @asmorkalov. The test Why does Previous implementation:
New implementation: If we set My preferred solution is to reduce the number of false positive detections by setting the default What do you think @asmorkalov ? Note that setting
|
…olini/opencv into pr-aruco-identification
|
Hi @asmorkalov, the default check is failing in |
|
Hi @asmorkalov, I'm still interested in this PR to reduce the chance of false-positive detections. Is there a path forward despite the new parameter? |
| static constexpr float kDefaultValidBitIdThreshold{0.49f}; | ||
|
|
There was a problem hiding this comment.
Why do you need it as dedicated constant? I propose to remove it from API and just stay it as field initializer.
There was a problem hiding this comment.
Why do you use 0.49 by default, but force 0.5 in tests? M.b. better to have 0.5 by default and do not touch tests (cover the default params in the tests).
There was a problem hiding this comment.
Hi,
Why do you need it as dedicated constant?
I need it to make sure that the legacy Dictionary::identify function uses the same default as the default DetectorParameters
I propose to remove it from API and just stay it as field initializer.
I'm not sure to understand, could you please provide more details?
Why do you use 0.49 by default, but force 0.5 in tests?
Please see #28289 (comment), which explains the reasons behind 0.49 vs 0.5. Note that in both cases some tests will fail.
There was a problem hiding this comment.
Let's rename the constant with capital letters LIKE_THIS. It's common OpenCV style.
There was a problem hiding this comment.
updated, what about the 0.49 vs 0.5?

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 #23190 in which we've introduced a pixel-based confidence in the marker detection.
Solution: Include a new parameter:
validBitIdThresholdused 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:
CV_ArucoDetectionThreshold,CV_InvertedArucoDetectionThresholdvalidBitIdThresholdon false positives was also tested using the benchmark dataset:MIRFLICKR-25khttps://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:5942false positives forvalidBitIdThreshold = 0.5629false positives forvalidBitIdThreshold = 0.49and0.469.5when compared tovalidBitIdThreshold = 0.5139false positives forvalidBitIdThreshold = 0.43and0.442when compared tovalidBitIdThreshold = 0.5Dicts 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_1000is commonly used.In the image attached, the values of
validBitIdThresholdtested 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.90fSummary of the results: summary.csv
Note that we can also analyse the number of false positives per marker
id. For example, here's the histogram for the dictDICT_4X4_1000. (The CSV attached contains all the results)For example, the marker id 17 is detected 252 times with
validBitIdThreshold = 0.5and only 34 times withvalidBitIdThreshold = 0.49. Looking at marker 17 (see below), we understand that this simple pattern randomly occurs in images.Results for every dict and every
validBitIdThresholdper_id.csvMissing 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.4allows to maintain a high recall in all conditions.Pull Request Readiness Checklist
Patch to opencv_extra has the same branch name.