W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2011

RE: use cases not covered by media capture under DAP

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 1 Dec 2011 01:08:47 +0000
To: Rich Tibbett <richt@opera.com>, Brian LeRoux <b@brian.io>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381C01C2@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
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:
>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
>'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]
>> [3]
Received on Thursday, 1 December 2011 01:09:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:34 UTC