Vis detection candidates of code marker

Detection candidates of code marker is visualized at frames also after this candidate has been found.

added low label

assigned to @a.seemann and unassigned @d.kilic

Wanted to add: Currently only one code is drawn every frame, no matter how many were found.

Just a few thoughts (more general about the visualization):

We need to

• set the recognized and rejected markers (findCodeMarker alone)
• add a recognized or rejected marker (findMulticolorMarker with its multiple calls)
• erase all Markers saved in the last frame
• set a different offset for each marker individually (only findMulticolorMarker)

The erasure is a problem with the visualisation of the code marker as well. If you activate it, perform recognition and then deactivate it, the drawn markers stay in place.

So my proposal:

• Since the markers need to be erased each frame, that should be done in UpdateImage
• Markers should be saved with an individual offset no matter if they are from the code marker or from the mulicolor marker with code (so the type of mCorners and mRejected would be something like std::vector<std::pair<std::vector<cv::Point2f>, Vec2F>>)
• Replace option of setting markers with an option to add them (erasure is dealt with in updateImage). I'd imagine a declaration like void addDetectedMarkers(std::vector<std::vector<cv::Point2f> > corners, std::vector<int> ids, Vec2F offset = Vec2F(0,0)); (since the offset for each call to the function should stay the same)

One might prefer a Struct over a std::pair.

unassigned @a.seemann

assigned to @d.kilic

created branch 71-vis-detection-candidates-of-code-marker to address this issue

mentioned in commit 9c36b721

mentioned in merge request !73 (merged)

mentioned in commit e91c65b1

@a.seemann I looked at the difference again. It's just that Code Markers at the edge of the head are detected less frequently. Which makes sense.

Multicolormarker:

Codemarker:

I don't see a difference with which markers get detected, but rejected.

mentioned in commit 069076c7

mentioned in commit 840fec65

closed with merge request !73 (merged)

mentioned in commit b62ee418

mentioned in issue #172 (closed)