Fix used corners being returned from mrcal and persist corner ids - #2574
Fix used corners being returned from mrcal and persist corner ids#2574thatcomputerguy0101 wants to merge 9 commits into
Conversation
github-actions
Bot
added
the
backend
thatcomputerguy0101
left a comment
thatcomputerguy0101
left a comment
There was a problem hiding this comment.
Part of why the old implementation seemed to work is that OpenCV outputs sorted corners, so most partial detections were probably being marked as outliers.
c00da1a to
8cbc20c
Compare
| level = 0.0f; | ||
|
|
||
| if (ids.rows() == params.boardWidth * params.boardHeight) { | ||
| // OpenCV detector always outputs corners sorted by ID, so it is safe to not sort the |
There was a problem hiding this comment.
Sorts are generally very cheap anyways
There was a problem hiding this comment.
This now has an extra-cheap sort implementation that takes advantage of the ids being a continuous range.
| // Decimation was not used | ||
| level = 0.0f; | ||
|
|
||
| if (ids.rows() == params.boardWidth * params.boardHeight) { |
There was a problem hiding this comment.
new sorting algorithm here, but I don't think any of our unit tests make assertions directly against findBoardCorners -- we just do it in a roundabout way that the calibration parameters are vaguely correct. If this code is no longer just plumbing lists out of opencv, let's add some sort of tests?
There was a problem hiding this comment.
Fair enough. I was considering writing tests, but decided not to at the time since isolating the sorting algorithm was a little hard. I'll give it another try though.
812b310 to
e46ef47
Compare
2 participants
Description
What changed?
This updates to a fixed version of mrcal-java that returns a list of corners used corresponding to the same subset of corners it was provided. Additionally, this persists the corner ids so that further processing of the board knows which subset of corners it is working with, and updates one of the test calibrations with the ids. The storage space could probably be optimized slightly by dropping the list of ids if all corners are detected, but that gets slightly complicated if the ids are unsorted so it wasn't implemented yet.
Why?
#2344 depends on the stored calibration point information being accurate. It wasn't before.
Testing
Related Issues
Blocked on PhotonVision/mrcal-java#31.
AI Disclosure
Describe AI involvement here if applicable
Merge Checklist
Additional Checks (if applicable)
./photon-client/src/types