Giter Site home page Giter Site logo

immersive-web / raw-camera-access Goto Github PK

View Code? Open in Web Editor NEW
37.0 37.0 12.0 117 KB

Spec draft: https://immersive-web.github.io/raw-camera-access/. Repository for experimentation around exposing raw camera access through WebXR Device API. Feature leads: Piotr Bialecki, Alex Turner, Nicholas Butko

License: Other

Makefile 1.83% Bikeshed 98.17%
incubation webxr

raw-camera-access's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

raw-camera-access's Issues

When will this be shipped?

When will this feature be shipped? There is no way at the moment to use it on edege for hololense since it is only on chrome. Or am I wrong?

Notes from Face To Face 4/21/2022

We discussed the current shape of the API at the Immersive Web Working Group Face to Face.

There’s a growing recognition in the working group that a lack of camera access has held back adoption of WebXR compared to alternatives like getUserMedia. The ironic effect of having an artificially limited api is that it pushes people toward less privacy sensitive alternatives. The goal should be to have user consent that is potentially improved from existing flows (whatever that entails) but is powerful enough to empower the gamut of valuable developer use cases.

In order to make the current proposal fully compatible with headsets, the following changes might be needed

  • frames are not coupled to XR frames, but come on a callback or some other mechanism
  • frames are timestamped
  • camera to viewer transform
  • field of view for camera is provided

Here are some examples of reasons developers choose use alternatives to WebXR because this API is lacking:

Interoperability and compatibility - web developers support

I'm preparing to kick off blink launch process for Raw Camera Access API, and one part of the Intent To Ship asks for signals from web developers - please take a look and let me know what you think! If my understanding is correct, we're looking for feedback along the lines of "the API [does / does not] solve my use case with [no / some / major] issues/workarounds needed", but don't feel limited by this formula!

So far the I'm aware of an issue around API ergonomics (see comment) - I think this can be tackled at a later stage, let's get the API out the door first and see what the main pain points are.

Pinging folks that may have some thoughts here: @nbutko, @tangobravo, @mrdoob, @elalish.

Explainers should lead with sample code, should not include IDL

Via the I2S thread, I started reading the explainer, and it seems like several best practices are missing and design directions are not enunciated:

  • the end-user problem/benefit is not front-and-center
  • the explainer includes proposed IDL, which should be relegated to a spec draft
  • the explainer does not identify problems related to XR camera access that are not going to be addressed by the design (non-goals)
  • the explainer is hand-wavey about why this is not being proposed as an extension to getUserMedia()
  • why does the explainer not provide a way to also upload "raw" image data to a WebGL texture?
  • for a "raw" image, the API seems to lack color space controls/hints/output, and does not document the format of the resulting texture. Why not?
  • how does this feature handle multiple cameras? Stereo cameras? Why are views and cameras always linked 1:1?
  • how will this work in the context of Offscreen Canvas?
  • the considered alternatives section only contains a single other design, when we can easily imagine many different designs
  • the spec doc does not link to the explainer
  • the explainer does not link to the spec

Potentially resolving the privacy sensitivity issue

I understand there has been TAG feedback regarding the privacy concerns and how we can inform users of the risks.

Where it's difficult to explain to users the potential risks in giving a website unfettered access to their camera as they move around their environment pointing it at possessions and loved ones.

I would like to propose that WebXR features could be split in a way that is similar to position tracking's fine grain coarse grain approach. Where for us coarse grain are the privacy preserving approaches and fine grain are the ones that give more power to the developer at the risk of user's privacy.

This way we can encourage developers to not rely on the availability of the API because user's may choose not to allow it if they are in an inappropriate place and the developer should instead try to use a fallback behaviour to provide an approximate experience or an alternative experience.

Example of an interface showing a radio button for how much power to give

Can this allow for deferring of camera output on mobile devices?

Hi,

Thanks for putting this together, it's exciting. Can this indirectly also allow for deferring the output of particular camera frames? And if so, what would be the best way to use the API in order to achieve this goal?

There's a full thread about the usecase for deferring output of camera frames is here - immersive-web/webxr-ar-module#44

But I think @nbutko 's usecase explanation here is the most succinct I've seen:

Delayed drawing - on mobile phones an application might need to synchronize the vision with the camera feed.
-- Need to be able to hold an XR frame for ~2-10 animation frames before it is presented to the user with other results from vision.
-- from immersive-web/proposals#4 (comment)

(With the caveat is that we're doing remote rendering and need to sync that to the camera output, rather than syncing CV stuff. But the requirements are the same for both.)

How to get access to the pixels

Hello.

I just worked on my code that used the camera-access as it was implemented until Chrome 91.

Access to the camera works it seems, as I can run the sample code provided at the Chromium site successfully. But I fail to get the pixels out of the WebGLTexture object returned by glBinding.getCameraImage() call now.

As WebGLTexture is described as an opaque texture object, I assume that accessing the pixels is not meant to work. But as computer vision is listed as one of the use cases in the explainer, I have the impression access to the pixels is necessary somehow.

Would be interested what the situation and plan is around this subject.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.