Re: PROPOSAL: Simple image capture API

On 3/13/2012 4:17 AM, Anant Narayanan wrote:
> 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.

Is this an area where events on mediastreams could 'bubble' up the chain 
of mediastream/etc objects to the camera drivers?  Like requests for 
flash, resolution changes, parameter changes, etc?  (and perhaps similar 
issues for audio - echo cancellation, gain control, etc)

Ignore syntax and naming:

     stream = navigator.getUserMedia(blah);
     preview.src = stream;
     ...
     (user clicks)
     stream.capturePicture(blob, whatever);
     or
     stream.sendEventToSource(event that tells camera to fire flash, 
change res, change ISO, etc).

The complication is that you may want to capture an image in sync with 
flash, so that might need to be handled via the capturePicture method 
(or event).

Also, do we need to know when these changes take effect?  Should such 
notification be in-stream (which allows immediate response with things 
like MediaStream Processing) or out-of-stream (which may be gated on 
main-thread response time).

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 13 March 2012 17:04:32 UTC