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

Note: this is how the Windows 8 Camera capture API [1] is factored. The object basically looks like this:

interface MediaDeviceControlCapabilities {
  float value;
  float min;
  float max;
  float step;
  float default;
  boolean supported;
  boolean autoModeSupported;
}

Pros: it does nicely factor the capabilities into an object-centric view
Cons: it leads to additional nesting in a constraint package (which may be OK): { videoWidth: { min: 1024, max: 1920 }}

[1] http://msdn.microsoft.com/en-us/library/windows/apps/windows.media.devices.mediadevicecontrolcapabilities.aspx


> -----Original Message-----
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> Sent: Tuesday, September 11, 2012 3:23 PM
> To: Josh Soref; Media Capture
> Subject: RE: Settings retrieval/application API Proposal (formerly:
> constraint modification API v3)
> 
> The MinMaxCurrentValue object is interesting.  I suppose that there
> could be another one EnumedValCurrentValue for settings that have a
> discrete set of legal values.
> 
> - Jim
> 
> -----Original Message-----
> From: Josh Soref [mailto:jsoref@rim.com]
> Sent: Tuesday, September 11, 2012 5:52 PM
> To: Media Capture
> Subject: RE: Settings retrieval/application API Proposal (formerly:
> constraint modification API v3)
> 
> Giridhar wrote:
> > 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 Geolocation API is generally understood to be a pretty terrible API
> in a number of ways. Referencing it isn't a good start to any argument.
> 
> Another example of a crappy API is the DeviceOrientation API which was
> published by the same WG. It basically has ZERO interop.
> 
> > 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.
> 
> So, "face detection" is an interesting thing. However, while it /may/ be
> possible to get interop in the form of "returns a rectangle that may
> have a fuzzy face, or an animal, or a statue, or a sculpture, or
> something that isn't remotely like a face", I'm not quite sure we're
> likely to see better interop than that. And I'm really unsure we'd be
> able to get interop on "how much padding will be included in the
> detected face boundaries".
> 
> An interesting question is can a face region have multiple faces?
> Would it be legal to return the entire picture's dimensions (for the
> case of a family/team picture, as opposed to an actual badge-photo)?
> 
> Calling those QoI distinctions is pretty problematic. If half of the
> implementations do it one way, and the other half does it the other way,
> you really don't have interop, and Cordova/jQuery and similar groups
> will be forced to just write their own shims which do detection they
> want manually (and more accurately). By that point, we've just mandated
> implementing something that doesn't work (and does add
> security/stability risks) and won't be used.
> 
> > boolean geotagging;// Default is false; true setting may be ignored if
> UA doesn't support.  Note that if UA does not support JPEG then this
> feature is disabled.
> 
> If the UA supports TIFF instead of JPEG, then I'd expect the tags to be
> available.
> I'd also expect the tags to just be available from the interface, in
> case I'm using PNG and just want to read the tags straight from the
> system instead of out of the image.
> 
> I'm also pretty sure that the part of speech for your boolean is wrong.
> "includeGeotags" or similar is probably better.
> 
> There's a similar risk for geotagging. I'd actually prefer that the
> geotag be specified as "include a location coord with precision
> indicator", this is distinct from features I've seen elsewhere where
> such coords are also converted to supposedly human readable strings (but
> which may be in all sorts of random languages, with misspellings and
> other amusing errors -- this is based on my work @nokia on the n900).
> 
> > boolean highDynamicRange;// Default is false; true setting may be
> > ignored if UA doesn't support
> 
> Similarly, I'd expect "captureHDR" or "useHDR" or something.
> 
> Personally, on the subject of how things should be shaped, I suspect I'd
> rather a single object attribute for a set of related things:
> 
> Interface FloatMinMaxCurrentValue {
>  float value;
>  float min;
>  float max;
> }
> 
> Interface SharpnessConstraints {
>  FloatMinMaxCurrentValue sharpness;
> }
> 
> Interface RotationConstraints {
> FloatMinMaxCurrentValue rotation;
> }
> 
> Interface BrightnessConstraints {
> FloatMinMaxCurrentValue brightness;
> }
> PictureInfo implements SharpnessConstraints; PictureInfo implements
> RotationConstraints; PictureInfo implements BrightnessConstraints;
> 
> One advantage of this, is that people are much less likely to misspell
> things.
> I'm speaking as someone who just spent a week cursing a dozen groups for
> not being able to spell words (jQuery: Suppress has two p's, WAI:
> labeled does not have doubled L's, qunit: grr, jasmine: grr, ...).
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> 
>

Received on Tuesday, 11 September 2012 22:57:39 UTC