WebXR Image Tracking API suddenly doesn't work

[Seonghoon-ban]

I developed and tested an AR environment based on image markers using WebXR's Image Tracking API about a month ago.

I checked all developed files work in the https environment, and the target gltf file was placed on the image marker properly. However, after a month has passed, and recently running in the same file and environment, we found that the gltf model is not attached to the image marker but continues to be located in the reference space (guessing as to the origin).

There is no special error, and as a result of checking in the code, image tracking seems normal. but in the below code, that pose could not be obtained properly (both position and orientation output 0,0,0)

const results = frame.getImageTrackingResults(); for (const result of results) { const image_pose = frame.getPose(result.imageSpace, refSpace); }

Both Chrome and OS versions are up-to-date, and the chrome flag is also set. Please help if anyone is experiencing a similar issue.

Many Thanks,

[reconlabs-sergio]

I confirm this. The getPose method always returns 0. I tried this with several chrome versions:

Chrome 89.0.4389.105: working Chrome 91.0.4472.120: not-working Chrome 91.0.4472.77: not working.

EDIT: Also tried in Chrome Dev 95.0.4551.2, and position is still zero.

@klausw, is there something new in the API that we are missing?

[klausw]

Do you have a link to an example showing this issue? I just tried https://arimg.glitch.me on the following versions, and it worked for me:

Stable: 91.0.4472.120 Beta: 92.0.4515.70 Canary: 93.0.4556.0

( This requires "WebXR Incubations" to be enabled: chrome://flags#webxr-incubations )

Here's an example of the getPose result:

XRPose {transform: XRRigidTransform, emulatedPosition: false}
  emulatedPosition: false
  transform: XRRigidTransform
    inverse: XRRigidTransform {position: DOMPointReadOnly, orientation: DOMPointReadOnly, matrix: Float32Array(16), inverse: XRRigidTransform}
    matrix: Float32Array(16)
      0: -0.9018635749816895 1: -0.05716412514448166 2: 0.428221732378006 3: 0
      4: 0.3559693694114685 5: 0.46333321928977966 6: 0.8115466833114624 7: 0
      8: -0.24480068683624268 9: 0.8843384385108948 10: -0.39751458168029785 11: 0
      12: -0.08360739052295685 13: 1.0077542066574097 14: -0.4341367483139038 15: 1
  orientation: DOMPointReadOnly {x: -0.08988568637769888, y: -0.8310703718374373, z: -0.5101508972034067, w: 0.202456569468499}
  position: DOMPointReadOnly {x: -0.08360739052295685, y: 1.0077542513608932, z: -0.4341367483139038, w: 1}

[klausw]

I have a likely suspect for this - can you please add yourself to https://bugs.chromium.org/p/chromium/issues/detail?id=1224598 where I'll continue investigating? Also, please note there which reference space type you're using. If I remember right, the arimg.glitch.me sample uses local-floor, and the issue may be related to XR spaces being erroneously treated as equivalent when they aren't.

[Seonghoon-ban]

I used 'local' as XR space. Now I confirmed it works with 'viewer' XR space for reference space.

Thank you @klausw!

[fabian-muff]

Is there a difference between the versions for devices? For me the image-tracking works on Android Chrome, but not on the HoloLens Edge (v. 95....) which should also include this experimental feature or not? Is this feature only shipped for android versions?

[papadako]

Hello,

Does anyone have problems with the current chrome stable (106) / canary (109) versions? It seems like the camera autofocus does not work and the camera is constantly focused at infinity. As a result, there is a problem recognizing of images close to the camera also.

[klausw]

The current Chrome implementation turns on autofocus if there is at least one trackable image in the supplied set of images: https://source.chromium.org/chromium/chromium/src/+/main:device/vr/android/arcore/arcore_impl.cc;l=478

Please confirm with getTrackedImageScores() that at least one of the images you've supplied returns trackable.

Also, please note that this API is currently on hold due to lack of consensus in the immersive-web group, and there aren't any concrete plans for launching it at this point. This may change in the future, but please don't depend on the API for critical web applications.

We're separately investigating turning on autofocus by default for XR sessions, independent of image tracking.