Re: Image Capture Proposal, second version

Hi

The new proposal certainly looks promising from my perspective. Being able to grab frames from the MediaStreamTrack simplifies a lot and I am really happy with the solution.

Some minor concerns:

1. Settings for video feed and photo capture is done differently, if I'm not wrong.
* Video (MediaStreamTrack) specific settings are passed to gUM as constraints (fill light on or white balance). These will affect getFrame.
* Photo specific settings are set on the ImageCapture object. These will not affect getFrame.
It seems to me that you are looking into this.

2. Could there be devices that take pictures but does not provide live video via a MediaStreamTrack? (Such as a connected SLR camera)

3. PhotoSettings: I'm really new to WebIDL, but shouldn't PhotoSettings be a dictionary or a callback interface?

Thank you for taking our suggestions into consideration :)

-Johannes

On Feb 22, 2013, at 11:30 PM, Mandyam, Giridhar wrote:

> Hello All,
> Thanks for all the detailed feedback I received on this.  I've now come up with a second version, which I have enclosed as an attachment. I have kept the first version up at http://gmandyam.github.com/image-capture if anyone would like to compare this one with the previous version.  
> 
> -Giri Mandyam, Qualcomm Innovation Center
> 
> Among the main changes:
> 
> a) Added a constructor to the ImageCapture interface.  The constructor currently takes a MediaStreamTrack as the argument because I wanted to keep the current version of the doc consistent with the latest Editor's Draft of the Media Capture spec (http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStreamTrack).  Once VideoStreamTrack is incorporated into the Media Capture spec, I will modify this doc accordingly with a VideoStreamTrack as the contructor argument.  
> 
> b) Added a getFrame() method that returns an ImageData object, plus a (pseudo) code example.  
> 
> c) Changed the event raised when taking a photo to a BlobEvent to remain consistent with Recording API spec.  Also, this needed to be changed anyways since the constructor was not consistent with the DOM4 spec.
> 
> Additional notes:
> 
> a) Kept the "photo" prefix on the event handlers to distinguish from the new frame grab event handlers.
> 
> b) I think we are starting to go around in circles on constraints versus settings. The way I interpreted Dan/Travis's presentation at the last interim (http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf), tracks are the only constrainable objects (see Slide 9).  If we approach constraints as per https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html, then one possibility could to define an ImageCaptureTrack-type object (which I believe was in V4 of Travis's proposal).  However, I believe the group consensus was against having a track specific to image capture.  So I stuck with settings n this draft.   I think the Recoding API should also implement settings (as opposed to constraints).
> 
> Some concerns:
> 
> a) A minor one:  VideoStreamTrack's should have readonly width and height attributes IMO.  This should be easily derived from the constraints that are applied in creation of the VideoStreamTrack.  The width and height attributes are required for the ImageData object that is returned when grabbing frames, and should not be different from the dimensions of the VideoStreamTrack.
> 
> b) As far as I can tell, there is no way to directly create an ImageData object in Javascript , e.g. var img = new ImageData(...), without a canvas context.  The getFrame() method however does not define any canvas context with the returned ImageObject.  If for some reason this is not acceptable, then width/height/data for the captured frame can all be returned separately.
> 
> <Mediastream Image Capture.htm>

Received on Monday, 25 February 2013 19:31:48 UTC