Re: Depth image capture workflow proposal for Web

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.
>
> [...]
>
>> 2. capture pipeline: by new ImageCapture(stream) in image capture pipeline. I propose to extend constructor of ImageCapture to take a MediaStream object instead of MediaStreamTrack object for aligned color+depth use case.
>> 3. request a capture sample: by grabFrame().
>> 4. data access: by extending FrameGrabEvent with depthMap. For {'video': true}, only imageData is populated. For {'depth': true}, only depthMap is populated. For {'video': true, 'depth': true}, imageData and depthmap are populated by aligned capture.
> Giri, All - I'm wondering whether we should expect the mediacapture-image spec [1] to evolve into a direction to allow reuse outside MediaStreamTracks of type "video". For example, allow passing MediaStream to the constructor to be able to handle use cases that involve MediaStreams composed of multiple MediaStreamTracks, potentially of different type. We could do that while we maintain backward compatibility with the current API by:
>
> [[
>
> [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?)

>   enable extensions such as:
>
> [[
>
> partial interface FrameGrabEvent {
>    readonly attribute DepthMap depthMap;
> };
>
> partial dictionary FrameGrabEventInit {
>    DepthMap depthMap;
> };
>
> ]]
>
> I observe the interface name "ImageCapture" may not be a perfect match for a more generalized API, but the ship may have sailed on the name (has the feature shipped btw?). If we could still rename things, "MediaCapture" would perhaps be a better name for a generalised API that's able to extract also other data than ImageData our of MediaStreamTracks or MediaStreams. But I don't want to bikeshed about naming at this time :-)

ImageCapture has not been shipped.

>
> Thanks,
>
> -Anssi
>
> [1] http://w3c.github.io/mediacapture-image/

Received on Wednesday, 18 March 2015 15:36:07 UTC