Re: First stab at the Capture API (aka Camera API)

On 4.12.2009, at 16.52, ext Robin Berjon wrote:

> On Dec 4, 2009, at 15:23 , Ilkka Oksanen wrote:
>> To keep things simple in v1.0 most of the configuration could happen
>> through UI in native side. Resolution (and quality) setting is a  
>> special
>> case in a sense that it affects directly to the file size. Following
>> could happen more often if there is no way of hinting the preffered
>> resolution in the API.
>> - A widget allows user to set profile picture, max resolution is
>>  640x480
>> - Native camera has the default resolution of 1600x1200
>> - User doesn't change resolution and takes the profile image
>> - Widget uploads the image to server
>> - Server shrinks the image -> Bandwith wasted.
> There's an API for that!
> You would:
>  - get the image somehow
>  - assign it to an <img> element (visible or not); alternatively,  
> get a way of extracting HTML5 ImageData from it)
>  - if it's the right size or less, you're good, otherwise continue
>  - create a canvas element of the desired size, get its 2D context
>  - use c2d.drawImage(yourImg, 0, 0, width, height) (or putImageData  
> if you have ImageData)
>  - then return c2d.getImageData(), or c2d.toDataURL(), or whatever  
> newish thing that can return properly encoded image content
> Not perfect, but workable.

An ability to set a [lower] resolution would also help to minimize the  
run-time memory allocation which should make apps more responsive and  
generally perform better. I'm sure using a canvas element is not the  
most efficient way to resize images albeit I like your creative  
approach ;) I agree that the lack of a resolution option is less of an  
issue on {desk|lap}tops which have a faster CPU, plenty of memory and  
typically rather modest camera optimized for video conferencing.  
Canvas resizing would probably work pretty well in such scenarios.  
Regardless, IMHO we should at least think the potential performance  
implications a bit too (the lack of a quality option is less of an  
issue as it has less variation and more reasonable defaults across  

If we were to add an optional resolution option and would like to mold  
the API a bit to be more extensible I'd propose something similar to  

[Supplemental, NoInterfaceObject]
interface Capture {
     readonly attribute sequence<FormatData> supportedImageFormats;
     readonly attribute sequence<FormatData> supportedVideoFormats;
     readonly attribute sequence<FormatData> supportedAudioFormats;
     PendingOperation captureImage (in CaptureCB successCB, in  
optional CaptureErrorCB errorCB, in optional captureImageOptions);
     PendingOperation captureVideo (in CaptureCB successCB, in  
optional CaptureErrorCB errorCB, in optional captureVideoOptions);
     PendingOperation captureAudio (in CaptureCB successCB, in  
optional CaptureErrorCB errorCB, in optional captureAudioOptions);

interface captureImageOptions {
    attribute unsigned long limit;
    attribute double duration;
    attribute unsigned short width;  // [0, 65535] should be enough?
    attribute unsigned short height; // ditto ("640k is enough for  
everyone" etc.)

// ... the same for captureVideoOptions and captureAudioOptions


Received on Friday, 4 December 2009 15:58:47 UTC