I am using the Marker Tracking capabilities of Magic Leap 2 through its C-APIs. However, in the C-APIs it has been mentioned that the physical length of the marker (QR Code) should be known prior to the detection for the correct and accurate spatial alignment.
On so many situations, the user will not have this information or, will not be able to generate a marker which fits the exact requirements. Also, what if one does not know the QR Code physical dimensions required for the application? Typically, the end user should not care about this detail.
Hence, my question: Is there a way to get the length of the QR Code or the marker, during the runtime?
ML2 OS version: v.1.4.0-dev2
MLSDK version: v.1.4.0-dev2
Host OS: (Windows/MacOS): Windows/MacOS
Currently our Marker Tracking API's do not support runtime Marker Size estimation. However, I have forwarded your feedback to our voice of customer team.
In the meantime, you could draw an input field and allow the user to manually input the marker size if it is deferent than your application expects. You can also create a marker with the expected size written next to the marker, similar to the marker used in the Workshop application.
Marker size estimation will be available in the final v1.4.0 release which is coming within the next few weeks. The support in Unity is likely coming in a later release.
Thank you for your reply and update. That is good news!
Also, on a distant but related matter,
is it also possible that you give access to the encoded raw qr data? Current behavior gives access to the decoded data rather than the data that is encoded in the qr. It would be helpful to give the user access to this raw data and provide them with option to decode through a call.
We're looking forward to your feedback once the size estimation feature is released in the SDK.
Concerning the raw data I would like to ask for some clarification:
- Are you referring to the case when the QR code contains binary data or are you referring to the raw data in the QR code modules including error correction bits, encoding indicators etc.?
- Could you explain how this could be helpful to you or your customers?
We have an internal logic to handle the raw encoded data and its decoding. I wanted to have access to the data in a state that it was read from the QR code. Without any decoding taken place.
You had mentioned that you will add marker size estimation in this release. I found out that you have added a header file and a .h/.cpp containing the logic for querying markers based on openxr calls. Namely: XR_ML_marker_understanding.h and MarkerTracking.h/.cpp files.
I want to implement the marker tracking using these calls. However, I have been unable to find any documentation regarding these calls and their arguments. As you may know, in OXR usually we need to supply a chained data structure for the functions. In some occasions, one needs to call a method multiple times to get the correct result. These characteristics makes working with OXR to require the access to the respective docs. Hence, it would be really helpful if you could provide the docs regarding these calls. I am writing this post since I have been unable to find any information on OpenXR Specs page nor in the aforementioned files.
Moreover, trying to initialise function pointers such as xrCreateMarkerDetectorML, xrDestroyMarkerDetectorML, etc. using the latest standard OpenXR Loader SDK (version 1.0.31), fails. Your documenation regarding OpenXR Runtime Setup, also, does not list the extension XR_ML_MARKER_UNDERSTANDING_EXTENSION as a supported extension. Hence, the question: How can I build openxr-loader with this extension enabled? Or, can you give us access to the openxr-loader library that you use for this extension?
tl;dr: The openxr methods are there, where are the docs? And how to get the extension in openxr-loader library?
Okay, we'll keep it in mind. We currently don't plan to expose the raw scanned QR code data, but I understand the benefits of it. We are making sure that we don't enforce a character encoding that may alter binary data in the QR code.
Regarding the OXR header, we'll provide a sample in an upcoming release and once the vendor extension has gone through committee approval the documentation will be online as well.
The extension is functional in the latest release and marker size estimation runs automatically when there's no marker size defined in the chained data structure for the configuration. Otherwise the API follows the common OXR paradigms.
Thank you for your reply. Your message is a bit vague for me and I do not quite understand what you mean by functional exactly.
Do you mean that if I use the OpenXR Loader library artifact build during the build of samples in the latest release i.e. 1.4.0, I can initialize the function pointers and get them during the run time?
If that is the case I do not understand how you are including this extension's implementation, since I have been searching for it in mlsdk. You mentioned the code has not been reviewed by the committee, and I know it is not included in the latest release of OpenXR-SDK i.e. (version 1.0.31) and nor it is in the OpenXR-SDK-Source repository which has the edge version of OpenXR-SDK.
That means one needs their own implementation for this extension. And as far as I know, that does not exist in mlsdk's code base downloadable by Magic Leap hub. By this point I am confused and I am scratching my head.
So, again, what do you mean by functional? Please point me to the implementation of this extension in mlsdk folder. And if possible, please, tell me how to build OpenXR-Loader so that it includes this extension.
If possible please provide me the OpenXR Loader Library that includes this extension namely (XR_ML_marker_understanding) or give me the steps to reproduce and rebuild it.
Also, if there are any data structures that need to be passed in a chained manner please list them.
Sorry for the vagueness, I had to double check internally to get more precise. Marker Understanding will be part of OpenXR v1.0.32, which should be released imminently. Then the documentation will also be available.