Tweak codec parameters to minimize false positives

[tpoxa]

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]

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]

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]

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

Thanks.

[qbonnard]

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

[tpoxa]

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

[lekevicius]

I have also noticed tag 14 appearing as false positive.

[qbonnard]

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]

14, 682, I also remember 683 one time.

[ayberkozgur]

I blame also 576.

[qbonnard]

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.