Image Capture Proposal

Hello All,
Here is a first stab at separated takePhoto() proposal.  You can also find it at http://gmandyam.github.com/image-capture/.  Some items to note:


a)      This proposal has dependencies on what we eventually decide on constraints/settings.

b)      When settings are requested through the setPhotoSettings() method and the UA cannot honor them (for whatever reason), then the appropriate error handler is invoked.  However, I have not defined any kind of error codes or error object for that matter to be passed back.  This could change in future revisions.

c)       A onphotosettingschange event handler can be specified.  This handler should be invoked any time a settings change occurs (which could happen without the setPhotoSettings method being invoked).

d)      I have not modified the White Balance settings mechanism (leveraging an enum) from the original proposal I made last year on camera settings.  But I am open to suggestions on this, as it seems there can be more flexible ways to specify this (see http://lists.w3.org/Archives/Public/public-media-capture/2013Jan/0005.html).

e)      I have changed ISO setting from an enum to a numeric setting within a range.  The UA should determine how to best match the specified ISO setting to the actual ISO values supported by the imaging device.

f)       I still have to verify the code example that I provided, and I intend to provide more examples.

g)      Under “Status of this Document” I currently have this as a deliverable of the Media Capture TF.  This is not accurate – it should be a deliverable of the WebRTC and DAP WG’s.  I will change this wording to match the wording in the Recording API and the Media Capture spec if the group decides that this document could become a specification from the Media Capture TF.

h)      If we do go forward with a separated takePhoto() spec, then the Recording API can be modified appropriately to leave the image capture method out.

Look forward to any comments/feedback/corrections/concerns.

-Giri Mandyam, Qualcomm Innovation Center

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Sunday, February 10, 2013 2:43 PM
To: public-media-capture@w3.org
Subject: Re: scope of media stream recording and capture specification(s)

On 02/06/2013 08:14 PM, Glenn Adams wrote:

On Wed, Feb 6, 2013 at 12:06 PM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
Glenn,
I agree that we need to clarify the relationship between our specs.  You are right that the GetUserMedia document describes how to create a local MediaStream.  However the WebRTC specification (http://dev.w3.org/2011/webrtc/editor/webrtc.html) allows you to create a remote MediaStream (one that’s getting its data from a remote peer.)  MediaRecorder should work with either type of media stream, so it’s not limited to local streams.

getUserMedia defines the general stream model. WebRTC builds upon that definition and extends it.
The intent of the recording spec is that one should be able to record any stream that builds upon the getUserMedia specification of MediaStream.



In addition to clarifying scope, I would suggest that the following members of the MediaRecorder API be moved to another, less general API or specification: image{Height,Width}, takePhoto, onphoto.


I think I heard people say at the interim that they thought takephoto() and friends should be moved to a separate specification.