The API only checks for identical images, meaning exact same target-files. A "DUPLICATE_TARGETIMAGE_USAGE" (error code 400, documentation will be updated on next deployment) will be thrown on target creation.
From your description, the "Similarity Check" Endpoint may help on that subject. But note that its's a crucial one. Usually, an image with a similarity score of 0.1 and below is safe to use, also in a target collection of 10k+.
Scores larger than 0.4 indicate that some areas of the images may get mixed up with at least one existing image (e.g. the top part of your image looks similar to the bottom part of an existing one = at least in terms of extracted features).
In case you plan to scale big and e.g. offer the user a way to augment their own targets, where mixing of augmentations is very crucial, I recommend you to reject images with a similarity score of 0.2+.In case you manage content on your own and there is no privacy issue in case you augment the wrong target, images below a score of 0.4 are fine to use.
At this point, I have to highlight that the similarity score comes without any guarantee. Especially in terms of privacy and protection of sensitive content I highly recommend to find other ways of separating and protecting user content - E.g. authenticate the user and bind users to isolated target collections and protect augmentation download on a session level.
Disabling targets is not possible, you have to delete them and trigger the cloudarchive generation in case you modify the collection via the API.
@Wikitude: if a developer uploads duplicate images, can you please allow them to choose what happens?
This is a good example for the variety of possible use cases of cloud recognition.
While others have to strictly avoid a mismatch of similar targets, your ideal cloud recognition mechanism should be lazy and return the most recent in case others look similar.
However, there is an easy way to map your requirements to the existing Wikitude CloudReco solution.
Please have a look at the meta-data attribute which you can optionally set per target (compare related SDK Sample). Assuming that you frequently update your vouchers, you may apply the following workflow for the "time relevant" ones (T):
Customers already used this mechanism to properly augment magazines which are shipped in different languages.
Hope this helps,
As written in my previous post, there is no need to delete potentially duplicate assets, it's about defining the right mechanism to map your requirements to the existing generic cloud recognition.
You have to arrange content and meta-data properly to take the right actions once a new voucher-action is released.
Your app needs to use cloud-recognition to find out which voucher-type (out of a set of similar vouchers) is scanned.
I hope you find a way to implement the desired app-behaviour. Please understand that we cannot provide "in-built" features for any use case but instead try to give customers advise during their previous concept and integration work via the forum and a ticketing system.