Re: Depth image capture workflow proposal for Web

On 03/19/2015 09:30 AM, Kostiainen, Anssi wrote:
> Hi Harald, Ningxin, Giri,
>   
>> On 19 Mar 2015, at 03:32, Hu, Ningxin <ningxin.hu@intel.com> wrote:
>>
>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>> Sent: Wednesday, March 18, 2015 11:36 PM
>>>
>>> On 03/18/2015 03:27 PM, Kostiainen, Anssi wrote:
>>>> Hi Giri, Ningxin, All,
>>>>
>>>>> On 18 Mar 2015, at 05:13, Hu, Ningxin <ningxin.hu@intel.com> wrote:
>>>> Ningxin - thanks for informing the TF mailing list of the recent
>>> developments.
>>>> [...]
>>>> [[
>>>>
>>>> [Constructor(MediaStreamTrack track),
>>>>   Constructor(MediaStream stream)]
>>>> interface ImageCapture {
>>>>    // ..
>>>> };
>>>>
>>>> ]]
>>>>
>>>> That'd allow other specs to reuse and extend ImageCapture APIs,
>>> I'd want to ask, though: Does the API that gets reused have to carry
>>> everything currently defined on ImageCapture?
>>>
>>> In particular, the PhotoCapabilities and PhotoSettings may not be applicable
>>> to something that captures something very different from images. (what's
>>> the whiteBalanceMode of a depthmap?)
>> I think PhotoCapabilities and PhotoSettings are only for color image capture. We may add DepthCapabilities and DepthSettings for depth image capture.
> Right. The photoCapabilities getter is currently specific to (color) image capture.
>
> Harald, Giri - what was the reason for not reusing the MediaStreamTrack.getSettings() accessor? To my untrained eye it looks as if that'd allow us to drop the ImageCapture.photoCapabilities attribute that is specific to image capture, and reuse what MediaStreamTrack has to offer (I'm missing earlier discussions around mediacapture-image, so sorry if this has been discussed before).

getSettings() is specific to the constraints model. Giri was of the 
opinion that he wanted a simpler model for settings manipulation than 
the constraints model used on MediaStreamTracks.

Received on Thursday, 19 March 2015 08:46:33 UTC