- From: Miguel Casas-Sanchez via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Dec 2016 18:23:37 +0000
- To: public-media-capture-logs@w3.org
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