Re: PROPOSAL: Simple image capture API

On Mar 13, 2012, at 2:04 AM, Harald Alvestrand wrote:
> I suspect that most stuff embedded within an application will want to control its own "viewfinder" UI, so that the more common flow will be:
> 
> getUserMedia(video: true....)
> <viewfinder code>
> getUserMedia(picture: true)
> <process snapshot>
> 
> Having the "preview to choose picture" dialog be required will make this use case more difficult.

This API is not targeted towards apps that need a custom viewfinder. If the app already has a MediaStream, it has no need to call getUserMedia again, rather extending/refining the MediaStreamRecorder object to allow for image capture is better (or do something similar to a getSnapshot() method proposed by Rich).

The proposed API is targeted solely at applications that only need a single picture without much fuss. The use-cases are simple: upload a profile picture to Facebook, or take a picture with Instagram and apply a filter, upload a picture along with your tweet. Note that cropping the picture, applying filters, etc. are done after the image has been captured in both of these cases, so a browser preview window is not a hindrance. If you look at the Twitter "native" app on Android, when you want to attach a picture with your tweet, it bounces you off to the default Camera app of the phone (which is the equivalent of the browser preview window in our world!), and after you take a picture you are returned to the app that asked for it.

I think it is important that we support these use-cases without a dependency on MediaStreams, with a dead simple API.

To be more specific I would like for this possible with just these few lines of code (renaming the function to avoid confusion with the existing meaning of getUserMedia):

navigator.media.capturePicture(function(blob) {
  // do something wit blob
}, function(err) {
  // show error message, or flash based fallback ;)
});

Separately, it is also important to define a similar function for capturing a picture from a live MediaStream, if the app already has one (currently it is quite clunky: https://gist.github.com/1852070).

It would be nice if we could reuse the same function signature and name for both of these cases, but if that only causes more confusion, then I'm OK with them being two separate functions (I do prefer reusing the same for both cases, though).

Regards,
-Anant

Received on Tuesday, 13 March 2012 17:55:29 UTC