I wanted to check if there is a bug in the implementation of the OpenXR based QR code tracking or if I am not using it correctly.
The problem that I am experiencing is two folds:
Using the OpenXR Api for Marker Tracking contents of the QR Marker sometimes are read false with gibberish text
The runtime creates new atoms for the same marker (even using accuracy profile)
I think these two issues are related. My implementation is close to the example code snippet on OpenXR Spec and I have to do manual filtering for multiple reporting of the same QR Code.
OS Version 1.4.1: MLSDK 1.4.0: Winows: (Windows/MacOS)
As stated under the post, the OS version is 1.4.1. And, It happens with physical separate QR codes that have the same tracking pattern. It happens in every run even if one provides the physical length of the QR code.
As a separate issue if one does not provide the physical length to the openxr runtime, the marker is found in a much greater distance than it really is. Approximately half a minute and sometimes up to a minute needs to pass so that the positioning and detection improves. However, the instantiation of multiple atoms for the same QR marker persists although, with lower frequency.
You created an AR application that creates a model at a specific QR Code location. When using the Magic Leap you notice that the marker tracker occasionally does not read QR Code properly which results in new atoms being created multiple times even if you're looking at the same QR Marker.
You also noticed that the object is created when looking at the same marker on two physically separate QR Codes.
And to make sure I understand your questions, you want to know :
Are developers expected to perform their own filtering to avoid spawning multiple objects at the same marker location?
Does the API provide a way to estimate the size of the marker if the physical length is not given?
What could cause the QR Code marker from being read incorrectly?