Re: [mediacapture-image] Use the constrainable pattern instead of creating a subtly different function set

Just to note that there are two kinds of options, those which result 
is applicable immediately, and the user reasonably expects to see its 
effect in order to iterate towards a solution, and the others, whose 
effect is not visible until the exposure takes place.

This is a table with the settings and their immediacy, i.e. are they 
reflected immediately in the captured Stream or is the effect delayed 
to exposure time:

| Setting | |
|---|---|
| whiteBalanceMode | immediate |    
| colorTemperature | immediate |
| exposureMode | delayed |
| exposureCompensation |  immediate |
| iso | delayed | 
| redEyeReduction | delayed |
| focusMode | delayed |
| pointsOfInterest | probably immediate |
| brightness | immediate |
| contrast | immediate |
| saturation | immediate |
| sharpness |  immediate |
| imageHeight | delayed |
| imageWidth | delayed
| zoom | immediate |
| fillLightMode | both |        

We could only pass the `delayed` ones to `takePhoto()`, all others 
need to be configurable separately: "live", if you want.  IOW, that'd 
effectively create two ways of configuring, which seem undesirable.  
Moreover, `zoom` is not the only "live" setting.

Would it be unreasonable to follow the technique in 
[`CanvasCaptureMediaStreamTrack`](https://w3c.github.io/mediacapture-fromelement/#dom-canvascapturemediastreamtrack)
 and define an `ImageCaptureMediaStreamTrack` where we could bundle 
_all_ options, to be configured via a constraint pattern? 

We'd still have the contention problem between the original 
MediaStreamTrack and the one controlled by `ImageCapture`, but that'd 
always be there because we are manipulating indirectly the hidden 
MediaStreamSource. 




-- 
GitHub Notification of comment by miguelao
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-image/issues/124#issuecomment-268318169
 using your GitHub account

Received on Tuesday, 20 December 2016 18:23:44 UTC