RE: PROPOSAL: Simple image capture API

This has been said already, but I'll say it again... If you want "dead simple", then you should use the declarative-based approach. You can take pictures and submit them to servers without any script at all. This task force isn't really looking at the declarative model, though DAP has the spec. I think your feedback is certainly relevant for that spec.

>-----Original Message-----
>From: Anant Narayanan [mailto:anant@mozilla.com]
>Sent: Tuesday, March 13, 2012 10:55 AM
>To: public-media-capture@w3.org
>Subject: 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 18:14:05 UTC