RE: use cases not covered by media capture under DAP

Great points Rich.

Since Canvas is so useful as a post-processing tool in the web today, the benefit that the Media Capture API can provide is high-fidelity images/video to feed to this post-processing tool :-)

I'll get these added to my scenarios list.

>-----Original Message-----
>From: Rich Tibbett [mailto:richt@opera.com]
>Sent: Wednesday, November 30, 2011 4:51 PM
>To: Brian LeRoux
>Cc: public-media-capture@w3.org
>Subject: Re: use cases not covered by media capture under DAP
>
>Brian LeRoux wrote:
>> Hey guys, I'm Brian and I work on the PhoneGap project. [1] We
>> implemented Media Capture. [2] It doesn't cover a number of use cases
>> so we have a complementary API of our own utility that covers the
>> common cases for image capturing discovered by PhoneGap app authors.
>> [3]
>>
>> Perhaps these real world cases can be of use.
>>
>> In particular things we see all the time:
>>
>> - image source (many camera sensors common now, select from photo
>> lib/gallary VERY common)
>
>The HTML Media Capture spec does provide an easy way to obtain 1 or more
>photo/video/audio files from a file system:
>
>http://www.w3.org/TR/html-media-capture/
>
>Would this gallery/lib 'capture' need to be real-time for any reason,
>and therefore manifest itself as a programmatic API for this purpose or
>would the above suffice?
>
>> - image destination (local to app, to the SD card, filesystem, as base64
>string)
>
>'Download to save' is something the majority of web users are familiar
>with today. When that mechanism gets triggered (by a user clicking a
>downloadable file) then files on the web don't have a destination per
>se. It's very much up to the user at the point of download where they
>want to save that file.
>
>It might be nice to provide a destination hint for a downloadable file
>but I'm uncertain on the exact use cases for that at this point.
>
>Alternatively, we could store all capture data in a common directory on
>the user's filesystem - so if required the user can go to that common
>file system location (e.g. ~/Pictures/web/) and obtain their generated
>image/audio/video data - or a native application can programmatically
>obtain files from that location since it always knows where to look.
>
>> - image quality
>
>If you copy the image data to a canvas element you can then get a data
>URI or blob where you can specify the desired encoding and quality e.g.
>
>canvas.toDataURL('image/jpeg', 0.6);
>// or
>canvas.toBlob(function(blob) {}, 'image/jpeg', 0.2);
>
>> - image rotation
>
>If you copy the image data to a canvas element and then obtain its 2D
>context you can then call rotate() on that context object to rotate the
>displayed 'image'. You can then obtain the manipulated image back via
>toDataURL or toBlob as above if you want to generate a file-like object
>that you can then pass around as required.
>
>> - image encoding
>
>See image quality above.
>
>--
>
>I wanted to record the above points in the discussion. I do like the
>efficacy of canvas to achieve any desired image manipulation (and soon
>to also be capable of audio manipulation).
>
>- Rich
>
>
>>
>> [1] http://phonegap.com
>> [2]
>http://docs.phonegap.com/en/1.2.0/phonegap_media_capture_capture.md.html#Ca
>pture
>> [3]
>http://docs.phonegap.com/en/1.2.0/phonegap_camera_camera.md.html#Camera
>

Received on Thursday, 1 December 2011 01:09:23 UTC