W3C home > Mailing lists > Public > public-immersive-web@w3.org > July 2022

Re: Raw Camera Access module - quick update

From: Simon Taylor <simon@zappar.com>
Date: Thu, 14 Jul 2022 14:56:05 +0100
Message-Id: <1172DB53-FE4D-401E-B03D-1E3119848773@zappar.com>
Cc: public-immersive-web@w3.org
To: Piotr Bialecki <bialpio@google.com>
Hi Piotr,

Thanks for the update, and your efforts to move this one forward!

Is your intention to have the current Chrome raw-camera-access implementation available without the feature flag?

I know we had a discussion some months ago at the face-to-face about various ways to expose raw camera access, in brief:

- Synchronous getter in rAF callback - current raw-camera-access implementation
- getUserMedia + new constraints - some support in the discussion, but I have some practical concerns
- A new “camera-ar” session type - would sit in IW’s sphere of influence (unlike gUM) and could share all the pose / anchor / etc functionality

I discussed the gUM and new session type options in the issue here: https://github.com/immersive-web/webxr-ar-module/issues/78 <https://github.com/immersive-web/webxr-ar-module/issues/78>

I think someone in the discussion at the f2f (Alex Turner IIRC) suggested writing up some pros/cons for various options on issues. I think I made a decent start on that in that issue, but I’m happy to do more work in that direction if there is value in it and if there is implementor interest.

I understand the easiest implementation to ship is the one that’s already there, so fully understand if you don’t have the resource or time to commit to any alternatives at the moment, but it would be good to understand the level of interest.

The camera-ar session feels relatively straightforward an implementation for mobile platforms, would completely address my concerns around giving up layout control to the “immersive” sessions, be easier to polyfill (eg on iOS Safari which lacks full screen atm), would support either “rendering effects” or “computer vision” use cases, and would be implementable on headsets too.

There’s likely a small performance cost on Android, as you’d need to blit the SurfaceTexture from ARCore to a framebuffer to support the more async access model through an ImageBitmap. I think the performance cost would be worth the benefits, and I believe the ARCore wrappers for various engines do this anyway (ref an old ARCore issue I opened in 2018: https://github.com/google-ar/arcore-android-sdk/issues/668 <https://github.com/google-ar/arcore-android-sdk/issues/668>)


> On 13 Jul 2022, at 18:31, Piotr Bialecki <bialpio@google.com> wrote:
> Hey Immersive Web!
> Just a quick update regarding WebXR's Raw Camera Access module. Latest state is that I've issued a PR <https://github.com/immersive-web/raw-camera-access/pull/12> that should address some concerns from TAG. After that lands, I'm planning on kicking off blink launch process which requires gathering signals from other browser vendors, so don't be surprised if you see some activity there!
> Thanks,
> -Piotr Bialecki

Received on Thursday, 14 July 2022 13:56:20 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 14 July 2022 13:56:21 UTC