W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2012

Re: PROPOSAL: Simple image capture API

From: Bryan Sullivan <blsaws@gmail.com>
Date: Sun, 25 Mar 2012 00:50:45 +0800
To: Harald Alvestrand <harald@alvestrand.no>, <public-media-capture@w3.org>
Message-ID: <CB941769.21FD6%blsaws@gmail.com>
Harald, FYI

To get your example to work, I had to replace:

         video.src = webkitURL.createObjectURL(s);

With

         video.src = webkitURL.createObjectURL(stream);


On 3/24/12 11:49 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

>On 03/13/2012 06:55 PM, Anant Narayanan wrote:
>> 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).
>Actually I don't think it is completely hopeless, the below works in
>Chrome canary:
>
><html>
><body>
><video id="v" width="300" height="300" autoplay></video>
><input id="b" type="button" disabled="true" value="Take Picture"></input>
><canvas id="c" style="display:none;" width="300" height="300"></canvas>
><img id="i">
></body>
><script>
>         var s;
>     navigator.webkitGetUserMedia("video,audio", function(stream) {
>         var video = document.getElementById("v");
>         var canvas = document.getElementById("c");
>         var button = document.getElementById("b");
>         var image = document.getElementById("i");
>
>         video.src = webkitURL.createObjectURL(s);
>         button.disabled = false;
>         button.onclick = function() {
>             canvas.getContext("2d").drawImage(video, 0, 0, 300, 300, 0,
>0, 300, 300);
>             var img = canvas.toDataURL("image/png");
>             image.src = img;
>             alert("done");
>         };
>     }, function(err) { alert("there was an error " + err)});
></script>
></html>
>
>(I had to twist Anant's example code in a few places to make it run)
>
>It doesn't do quite what you'd expect, though. I don't know if that's a
>bug or not.
>> 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 Sunday, 25 March 2012 07:51:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:09 UTC