RE: Image Capture Proposal, second version

Hello Johannes,
Thanks for the feedback.

> 1. Settings for video feed and photo capture is done differently, if I'm not wrong.

Your interpretation is correct.  For a video stream track (which has not been incorporated in the main Media Capture specification yet), you can find an example of how to apply video-specific constraints (changing zoom setting) in https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html#changing-zoom-in-response-to-user-input.

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

I'll admit that I addressed this API primarily from the perspective of what my company supports in the embedded space, and I think it is safe to say that all the major smartphone OS's support some form of preview stream when taking pictures through their native API's.  I assumed then that the preview stream would be available via a MediaStreamTrack.  Are you implying that there are digital cameras on the market that could support taking a picture without providing a preview stream?  If so, you are correct that the present API proposal does not account for such devices.

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

I'm having trouble finding a prohibition in the WebIDL spec against defining an object like PhotoSettings the way I did it, but I admit that at the very least I should've made PhotoSettings a [NoInterfaceObject].  Regardless, pretty much all the recent W3C specs that are defining an options object to be passed in a method are defining them as dictionaries so I think you are correct from that perspective (not to mention that web runtime engines that are migrating their IDL to WebIDL also leverage dictionaries for settings).  

-Giri

-----Original Message-----
From: Johannes Odland [mailto:johannes.odland@gmail.com] 
Sent: Monday, February 25, 2013 11:30 AM
To: Mandyam, Giridhar
Cc: public-media-capture@w3.org
Subject: 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 Tuesday, 26 February 2013 01:06:51 UTC