search

chili-epfl / chilitags

Robust Fiducial Markers for Augmented Reality And Robotics
http://chili.epfl.ch/software
123 stars 57 forks source link

Tweak codec parameters to minimize false positives #49

Open tpoxa opened 10 years ago

tpoxa commented 10 years ago

We are using chillitags in phototagging service. I wish to say thank you for all team for such great software.

Yesterday we notices that tag number 14 some time founds on photos where it is not presented. For example here https://drive.google.com/file/d/0B9u49XIS1iAFM1J3X1AyMC1LVzg/edit?usp=sharing or here https://drive.google.com/file/d/0B9u49XIS1iAFeS1iRWZNdUJZUHM/edit?usp=sharing Why this may happen?

Thanks again for your great work!

ayberkozgur commented 10 years ago

I also have had similar problems where some tags were detected in the distance where there are no actual tags. I've never had the chance to pinpoint the actual tag number that caused this, but # 14 seems like a likely suspect: Its black/white cell distribution is very unbalanced, there is a large area of white cells gathered in the middle which should be easy to find in non-tag images. A short-term solution would be to not use such tags in your application and discard them when detected.

qbonnard commented 10 years ago

Yes, that's a false positive issue :( They are rare, which is good in general, but bad for testing... @tpoxa do you mind if we include the sample you gave us into chilitag's test data ? I.e. are these public pictures ? We can blur faces too, or extract the area of the image where the falsepositive is detected if they are not.

Funnily (!) enough, this issue is related to @tpoxa first problem of not having enough tag ids, because we can probably tweak Codec's parameters to avoid such problematic tags.

tpoxa commented 10 years ago

Yes, sure, please use it. Would be great to mask faces, yes. I can give more examples if needed.

Thanks.

qbonnard commented 10 years ago

Thanks a lot ! Have you noticed other false positives than tag 14 ?

tpoxa commented 10 years ago

No, only this one. tag 14 Maybe because we have a few test cases.

lekevicius commented 10 years ago

I have also noticed tag 14 appearing as false positive.

qbonnard commented 10 years ago

Also only 14 for you too ? We could black list it like we did with #682 (which is completely black). It's more annoying, because it has a low ID and is more likely to be used. Then we could recommend another order of IDs to use that maximizes the hamming distance for each bit matrix to all previous ones. More simply we can advise in the doc (anyone reads that ?) to not use tag 14 (i.e. black-list it on the application side)...

lekevicius commented 10 years ago

14, 682, I also remember 683 one time.

ayberkozgur commented 9 years ago

I blame also 576.

qbonnard commented 9 years ago

OK, we should tweak the codec parameters to maximize hamming distance between codes, make sure they are not mostly monochrome, and have an order of ids that maximise hamming distance if taken from 0 to 1024... But that means breaking the backward compatibility, so I'm inaugurating a 3.0 milestone tag.