W3C home > Mailing lists > Public > public-media-capture@w3.org > September 2012

Re: Settings retrieval/application API Proposal (formerly: constraint modification API v3)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 10 Sep 2012 23:22:07 +0200
Message-ID: <504E59FF.6090008@alvestrand.no>
To: public-media-capture@w3.org
On 09/10/2012 06:44 PM, Mandyam, Giridhar wrote:
> Hello Rich,
>
> As I have already mentioned, these attributes can be made optional for the UA.
What does it mean that an attribute is optional? Does it mean that JS 
can probe for the function being present by detecting whether or not the 
attribute is present, or does it mean something else?
>    Moreover, the attributes I have proposed have working HW implementations that are on the market today, and are more efficient than achieving similar functionality in JS (in the cases where this is even possible).  I object to leaving such features out of the first version of the spec as well, as the timeframe of and commitment to a second version of the spec are unclear at this point.

The trouble here is that we're writing a standard. A standard that says 
"do whatever the camera manufacturer thinks is appropriate for a 
function with this name" isn't very interoperable.

Just defining what "skintoneEnhancement" means is a rich source of 
controversy.


>
> -Giri
> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: Monday, September 10, 2012 8:23 AM
> To: public-media-capture@w3.org
> Subject: Re: Settings retrieval/application API Proposal (formerly: constraint modification API v3)
>
> Harald Alvestrand wrote:
>> On 09/10/2012 04:21 PM, Mandyam, Giridhar wrote:
>> This proposed interface proposes adding at least 47 new attributes to
>> an interface that at the moment has something like two attributes
>> (mandatory and optional constraints). Several of these need
>> definitions that are not clear to me.
> We should separate the discussion like this: anything that is absolutely not possible to do via JavaScript today (e.g. set the flash, set the zoom mode, rotate the video stream, select the front/back camera, etc) should be added to this interface ASAP. Anything that could, at least initially, be modeled in JavaScript should be left out of a first version of the spec (i.e. anything to do with image processing such as faceDetection, skintoneEnhancement, redEyeReduction, etc). We can always add such things to browsers later of course*!
>
> We are specifically trying not to let this get too complex and laying the groundwork for something shippable in the short term. We want to ship something in 2012/2013 after all :)
>
> Kind regards,
>
> - Rich
>
> * Looking at some of the features of this proposal (e.g. faceDetection, skintoneEnhancement, redEyeReduction and to a slightly lesser extent saturation, sceneMode, iso, etc) we're going to need to document very extensive image processing algorithms in our spec and very extensive tests to ensure interop across different implementations for these methods. While some of those features will take effect at the source themselves, we are likely to require specific algorithms for fallback software implementation of these methods (where such features are not supported by web cameras themselves). That will be a lot of work.
>
>
Received on Monday, 10 September 2012 21:22:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:01 GMT