srobo / libkoki

A computer vision library for detecting and estimating the position of fiducial markers
GNU General Public License v3.0
7 stars 7 forks source link

Remove marker 131 #5

Open PeterJCLaw opened 5 years ago

PeterJCLaw commented 5 years ago

In SR2019 we discovered that marker 131 (which we were expecting to be used as a token marker) isn't actually readable by libkoki (https://github.com/srobo/game-markers/pull/5). We should therefore remove it from the set of valid markers.

Note: this issue might actually need fixing in https://github.com/srobo/kokimarker too, though I've a feeling that there's something in libkoki which enumerates the "bad" markers.

trickeydan commented 5 years ago

How about fix marker 131? We should probably try to find and resolve the underlying issue rather than ignoring it.

PeterJCLaw commented 5 years ago

That would be great, however I suspect not really worth the effort. As I understand it, libkoki can encode considerably more patterns than we actually use (somewhere between 200 and 300) so just killing off a known-bad one is easy and has very little negative consequences.

For info: a fix here would involve changing the code which does the recognition of the markers, rather than the marker itself. The markers are essentially an encoding of their number (plus some error correction), so changing the marker makes it wrong. There is then a mapping from their proper number to their exposed number, which keeps the public-facing sequence contiguous (i.e: 131 is likely the encoded value of something like 134 as we've already removed some bad markers previously).

kierdavis commented 5 years ago

There's a list of bad codes in both libkoki (https://github.com/srobo/libkoki/blob/master/tools/code_table.py#L5) and in kokimarker (https://github.com/srobo/kokimarker/blob/master/kokimarker/mapper.py#L15) which likely both need to be updated.

rgilton commented 5 years ago

This is obfuscated by #7. Let's not advance this ticket until that is resolved.