Image Capture Proposal, second version

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.