duplicates

[NiallTheNewMexican]

Hello! First off, your tracking scripts are quite robust. However, I seem to get duplicates of each marker that I track. I see that

markers_list.append(HammingMarker(id=marker_id, contours=approx_curve))

is the line that adds a marker to markers_list, but am unsure of how to make a line along the lines of:

if HammingMarker(id=marker_id): dont add

(I just started using python and opencv so excuse my possibly trivial question)

Also:

Is there a way to increase pose estimation accuracy? I implemented subpix and the persp_transf matrix is all over the place.

Thanks,

Niall

[DebVortex]

Hi Niall,

thanks for your post. Fist of all, allow me one question: how did you get here? Was this Repo posted somewhere? A few days ago, someone wrote me in #1 and then created a pull request. The whole Issue was more or like just a little experiment to play around with OpenCV as well as remind me how hamming code works. I was surprised that anyone found this Issue and now I get a second response?

Now to your topic/question:

Just checking for the ID would be not enough. Imagine the following situation: You make some kind of AR cardgame and use the IDs to represent the different cards. With the current setup, you could provide up to 4096 cards. In the end, you want to allow the players to have each card multiple times on the field.

The ID is just the numerical representation of the value the token represents. However, it would be possible to check the contours if they are overlapping each other.

To your estimation question: unfortunately no. The last time I really looked at the code was end 2014. I have not much experience with OpenCV and it would take some time to get back into it.

[NiallTheNewMexican]

Max,

Try searching "python marker detection" on google! Your project is the first link.

I understand your point about the duplicates issue, but my application will only have 1 marker of each id visible at a time, but may have multiple markers with different IDs on screen.

I've been working on an augmented reality script with opencv that basically takes corners of a square in the camera view and warps them to a perfect square and using the transformation matrix to warp the whole frame. I was hoping that your module would provide more accurate transformation matrices because there are just more features inside the marker.

Niall

On Tue, Apr 19, 2016 at 11:21 AM, Max Brauer notifications@github.com wrote:

Hi Niall,

thanks for your post. Fist of all, allow me one question: how did you get here? Was this Repo posted somewhere? A few days ago, someone wrote me in

1 https://github.com/DebVortex/python-ar-markers/issues/1 and then

created a pull request. The whole Issue was more or like just a little experiment to play around with OpenCV as well as remind me how hamming code works. I was surprised that anyone found this Issue and now I get a second response?

Now to your topic/question:

Just checking for the ID would be not enough. Imagine the following situation: You make some kind of AR cardgame and use the IDs to represent the different cards. With the current setup, you could provide up to 4096 cards. In the end, you want to allow the players to have each card multiple times on the field.

The ID is just the numerical representation of the value the token represents. However, it would be possible to check the contours if they are overlapping each other.

To your estimation question: unfortunately no. The last time I really looked at the code was end 2014. I have not much experience with OpenCV and it would take some time to get back into it.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/DebVortex/python-ar-markers/issues/3#issuecomment-212025032

[DebVortex]

Wow haven't expected that.

Unfortunately I'm not really able to help you. However, I could wrap my functions in the detect.py in a class. doing so, would allow you to inherit from it and then you could override the detect function but leave the rest intact. There are also two other projects you could take a look at:

• https://github.com/nkdhny/pyaruco a python ArUco wrapper
• https://github.com/pierre-rouanet/hampy which seems to be similar to mine (however, using hamming 7,4 instead of 4,3)

[calumk]

Hello - Firstly thankyou, Ive been using this library for a little while for some research Im conducting. Its very simple to use, but I also have the "dual detection of markers" issue that @NiallTheNewMexican described.

I havent had a chance to look into it yet, ill reply if i get a chance to fix it!

[DebVortex]

Hi @calumk,

thanks for commenting. Now that more people seems to get that error, I will look if I find the time to solve it. My approach would be to check that the contours of the markers don't overlap if multiple are detected. Do you think that could solve that problem?

[Zhouhao12345]

It is my stupid solution to solve this issue: try: marker = validate_and_turn(marker) hamming_code = extract_hamming_code(marker) marker_id = int(decode(hamming_code), 2) mark = HammingMarker(id=marker_id, contours=approx_curve) markers_list = [x for x in markers_list if x.id != marker_id] markers_list.append(mark) except ValueError: continue Your ar-hampy track tool is really useful, and suitable for any environment. However, the light changing still made effect on the marker tracking process. I will try some solutions to solve it :]

[DebVortex]

Hi @Zhouhao12345,

I guess you accidentally switched your both lines with the markers_list. Your solution solved the initial problem / question of this issue, that is correct. But as I mentioned in my first comment, it may not solve the problem. If you have the same marker 2 times, the detection may "jump" from one point to the other, because the wrong one is getting "kicked out".

Additional, It may be wanted to use the same marker twice at the same time. I would rather prefer some kind of kwarg to accept multiple use of an ID or not.

[DebVortex]

I don't have the time to do a configurable way of enabling / disabling duplicates. So I close this Issue for now. If anybody wants to take care of it or has Ideas/opinions, feel free to open a new Issue.