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

Since we do not have an API that directly exposes camera capabilities, I think that the developer should be able to probe for whether or not a feature is present.  This is what I was intending by making camera settings optional.   I understand the arguments against feature detection, particularly around device fingerprinting.  However, there is no guarantee that any of the camera settings proposed even before my most recent post (e.g. focus, zoom) will be exposed on all devices.  So I don't know how we can avoid allowing some level of feature probing that could result in fingerprinting.  BTW, there is a thread in the DAP WG discussing the topic of what to do when exposing an API on a device that doesn't support the feature - there aren't easy answers.

Regarding "do whatever the camera manufacturer thinks is appropriate for a function with this name", we do have precedence for providing implementation flexibility in the W3C.  For instance, the Geolocation API poses no detailed requirements on the underlying platform as to how to interpret the setting enableHighAccuracy.  The underlying platform could leverage GPS, or could use some form of proprietary triangulation, etc.  A standard in my opinion should provide some room for product differentiation.

That being said, I don't believe all of the attributes I've proposed are subject to multiple interpretations.  Brightness and contrast would be considered examples of this.  Maybe a more constructive way forward (as opposed to dismissing what I've proposed summarily) would be to at least determine those settings that would not derail the standardization effort significantly.
 
-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Monday, September 10, 2012 2:22 PM
To: public-media-capture@w3.org
Subject: Re: Settings retrieval/application API Proposal (formerly: constraint modification API v3)

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:53:09 UTC