Re: PROPOSAL: Simple image capture API

On Mar 12, 2012, at 4:14 AM, Rich Tibbett wrote:
> We've run in to the issue of having to figure out when and how to invoke (auto-)flash and (auto-)focus features to the web cam for the purposes of taking image snapshots via getUserMedia. The use case we had in mind is one of reading QR codes via the webcam:
> 
> http://shinydemos.com/qr-code/
> 
> Right now we aren't getting a consistently reasonable enough resolution for extracting the QR code from the image and there's currently no way to trigger the flash for low-light conditions. These are practical problems that we'd like to solve in the short term.

That's interesting. I think the 'snap a picture' use-case is distinct enough that it might warrant a separate function (see my other mail as response to Harald), and having these options for flash & resolution in that would make a lot of sense.

I'm trying to avoid a dependency on MediaStreams for the particular case where all the web page wants is a single image from the user's camera. Profile pictures, QR codes, there might be more…

> It seems that if you could synthesize click events on the input element approach presented above then you get this functionality programmatically without any additional API footprint e.g. input.click().

Synthesizing it using input.click() has some drawbacks, and I think it might have an impact on accessibility (I'm not sure but it rings a bell). It is certainly not very elegant :)

> I was hoping for something subtly different. More along the lines of extracting a still image from an already authorized MediaStream object. By default we'd have auto-flash and auto-focus enabled when the user called a getSnapshot (or some such API) method but let web developers override those settings at run time if they so wish.

I was hoping we would refine the MediaStreamRecorder to achieve this. But one interesting approach might be to expose a getSnapshot on a MediaStream that was already obtained, but also expose it under navigator.media. The former would result in no prompting, whereas the latter would show a preview window for user action.

> Anything that we can defer to the browser's chrome can be done through the declarative approach from DAP...and clicking that input button implies consent from the user. It is an implicit permissioning approach without cumbersome permission dialogs which is an excellent design IMO.

Well, browser chrome will be displayed even for getUserMedia() as currently specified. I think the distinction between the two types of UI is fairly thin. In fact, for Firefox, we hope to reuse a large part of the permission prompt to construct the preview window for {picture:true} - since we already plan on showing the user a preview of their cameras in the doorhanger for {video:true} before a MediaStream is authorized.

Cheers,
-Anant

Received on Tuesday, 13 March 2012 08:18:51 UTC