- From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
- Date: Wed, 2 Dec 2009 09:10:10 -0800
- To: "Arve Bersvendsen" <arveb@opera.com>, <public-device-apis@w3.org>
Hi Arve, Re your responses to my comments: " 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." [bryan] how then do we ensure interoperability, if it's not in a spec? Do I have to code my app for the specific implementation approach of the web runtime? That would not be good. " As for controlling which camera <input> would choose: I'm pretty sure a microdata approach would easily solve this " [bryan] Again, how/where would we define the use of the microdata normatively, to ensure interoperability? Best regards, Bryan Sullivan | AT&T -----Original Message----- From: Arve Bersvendsen [mailto:arveb@opera.com] Sent: Wednesday, December 02, 2009 9:03 AM To: SULLIVAN, BRYAN L (ATTCINW); public-device-apis@w3.org Subject: Re: <input type=photo> etc as Capture API On Wed, 02 Dec 2009 17:05:07 +0100, SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com> 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 http://bondi.omtp.org/1.1/cr/apis/camera.html#setFeatureN106F7 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, http://www.opera.com/
Received on Wednesday, 2 December 2009 17:10:56 UTC