Re: [mediacapture-image] Use constrainable pattern for ImageCapture (#124)

@miguelao Isn't there also `exposureMode`, `iso`, `focusMode`, and 
`fillLightMode` from your 
[list](https://github.com/w3c/mediacapture-image/issues/124#issuecomment-268318169)?

I don't have a concrete proposal, merely challenging what is most 
logical:
 * Separate video and photo settings is more logical, less convenient.
 * Single mechanism for settings is more convenient, less logical.

If we chose the former, any ranges for values of `takePhoto` arguments
 would not belong in `getCapabilities`, and would need their own thing
 IMHO, e.g. `getPhotoCapabilities()`.

>e.g. imageWidth might support any value between 400px and 4000px in 
steps of 100px

In a vacuum where constraints didn't exist, I'd say the most logical 
way to represent "delayed" (photo) settings would be an array of 
values for each thing, and then have `takePhoto` fail if called with 
values not in the array. No need for a separate "configuring" step, 
since you know all the valid settings. You're not configuring the 
device, you're configuring the shot.

If we chose the latter, for "delayed" (photo) properties which never 
collide, the `exact` keyword seems to exist solely to compensate for 
the lack of specificity in `getCapabilities()`.

I'm curious, how do we imagine a user "configuring" their device in 
the single constraints model? What would the UI look like? How would 
the app learn the discrete settings to offer as choices?

* Call `applyConstraints({imageWidth: {exact: w}, imageHeight: {exact:
 h}})` until it succeeds?
* Call `applyConstraints({imageWidth: {min: minWidthICanAccept, max: 
maxWidthICanAccept}, imageHeight: {min: minHeightICanAccept, max: 
maxHeightICanAccept}})` and hope it doesn't fail?

What's the ideal UI here? Maybe we should start there.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-image/pull/146#issuecomment-283531631
 using your GitHub account

Received on Thursday, 2 March 2017 01:53:26 UTC