Re: <input type=photo> etc as Capture API

On Wed, 02 Dec 2009 17:05:07 +0100, SULLIVAN, BRYAN L (ATTCINW)  
<> wrote:

> Re the proposal to use something along the lines of <input type=photo>
> to invoke a capture function, that is not an API, but a "user input
> selection method".

It would typically be:
- <input type="file" accept="image/*">
- <input type="file" accept="video/*">
- <input type="file" accept="audio/*">

> An API is a method via which an application invokes a
> function. There should be no inherent reason that the user must be
> involved in the invocation of that function (or that there is even a
> user present).

DOM events already provides the mechanism for invoking capture from an  
input control, by means of synthesizing a click event.  User agents in  
general will either ignore the synthesized event, or possibly throw a  
security error.

If you are operating in a runtime where the user has consented to a  
particular application accessing the camera, a user agent can probably be  
configured to allow the synthetication of said event.  I view this largely  
as an implementation detail, not as something subject for a spec.

The File API spec (what used to be "File Upload" would, once the data is  
captured, provide means of both accessing the captured data from inside  
the user agent.

As for controlling which camera <input> would choose: I'm pretty sure a  
microdata approach would easily solve this

> The BONDI Camera API provides a good model for how this should work. If
> W3C chooses to define only something along the lines of a <input
> type=photo> method, then I believe the market will quickly speak to the
> sufficiency of that approach, and other API designs such as the BONDI
> Camera API will be more successful.

What I have responded here does not actually deviate significantly from  
the existing editor's draft, it is just reusing existing constructs and  
semantics instead of having a subtly incompatible interface.

As for the BONDI Camera API (assuming is current):

* CameraFeature is underspecified
* No (proper) control over well-known camera features: sensitivity (ISO) ,  
aperture, exposure, focus. While there is some coverage over basic  
features, it seems to be limited to simple on/off for the feature, and the  
means of addressing features is underspecified
* No proper access to or control over EXIF data from the camera.
* The camera data stream is inaccessible, which in turn means:
   - no viewfinder
   - no realtime analysis of data, which means that you can't do face (or  
other feature) detection
   - No realtime transformation of camera data (think of  
SVG+viewfinder-stream, for instance)
* CaptureOptions tries to provide a means of setting resolution for  
capture, saying the camera itself will chose something arbitrary if the  
desired capture size is not available. The proper way to do this would be  
to let the camera expose which modes it supported natively
* Many modern cameras, and I'm pretty sure this is going to bleed over to  
mobile phones as well, offer dual-format capture (RAW/Jpeg), and the spec  
doesn't seem to be able to capture this.

* While this is probably outside of the set of use-cases for the mobile  
phone industry, lenses in typical DSLRs, Micro Four Thirds, and similar  
also carry data, which should be made available : supported apertures,  
focal lengths, manual/auto focus

This list is not to be considered a full review, it just provides some  
problems with the specification, where some of the problems are more  
important than others  - I wouldn't consider getting Panasonic's  
distortion data out of their lenses vital
Arve Bersvendsen

Opera Software ASA,

Received on Wednesday, 2 December 2009 17:03:46 UTC