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

On 7.12.2009, at 18.15, ext Robin Berjon wrote:

> Hi Anssi,
> [my spellchecker insists on calling you "ANSI"  you were meant for  
> standards!]

[that'll become my alt tag line for sure :P]

> On Dec 4, 2009, at 16:59 , Anssi Kostiainen wrote:
>> On 4.12.2009, at 16.52, ext Robin Berjon wrote:
>>> There's an API for that!
>> 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 ;)
> Right :) I was merely trying to push back (gently) to see if we  
> didn't have a simpler solution. I agree that there is value in  
> controlling the options (though I'd rather see them limited, given  
> the complexity that we can open up).

I agree that a minimum set of configurable options for v1 is the way  
to go. Resolution seems to be something we should be able to control  
programmatically due to the obvious impedance mismatch between what is  
a typical default resolution of a camera and what is required by a  
typical web service + performance concerns. I expect the gap to remain  
about the same -- the network and CPU speeds will improve, but so will  
cameras gain more pixels.

>> [NoInterfaceObject]
>> 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.)
>> };
> Writing the WebIDL is always going to be the easy part here :) Do  
> devices support setting width and height independently? If not which  
> one determines which resolution is chosen? How does one fallback?  
> There are plenty of annoying details to sort out here.

Flash Camera API setMode() as pointed out by Nick (thanks!) gives us  
some hints on how one could handle such details:


But you're right in that things will get trickier especially if fps  
(for video) is added into the mix. I assume we want to -- at least  
initially -- steer clear of specifying algorithms such as those  
described in:


As the above reference is fairly old (2005), I'd appreciate feedback  
from Flash gurus who have fiddled with the Camera API lately and know  
what the real issues are. Anyone?

A simple and naive way to handle the resolution would be to fail via  
en error callback if a capture* method is invoked using incompatible  
resolution. However, that would force developers to check for  
supported resolutions up-front via supported* if they do not want to  
stick with the defaults. Speaking of defaults, I feel that should be  
left to UAs (as opposed to Flash which dictates the defaults) as  
otherwise it would get outdated pretty fast (least common denominator).

> Also, looking forward to an embedded ViewFinder (I'd still like to  
> have some idea of how widespread and hard it is, what the platform  
> limitations are, etc.) shouldn't those options be directly  
> controllable on it?

I was thinking of something along the lines of the controls attribute  
of the video element but applied to the capture scenario:


-Anssi [meant for standards!]

Received on Tuesday, 8 December 2009 17:25:32 UTC