Re: Image Capture Proposal

I haven't had a chance to do an in-depth review, but this looks
reasonable on face value.

You have neglected to define the constructor though.  I assume that
you pass the MediaStream in.

On 15 February 2013 15:20, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> 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>
> 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.

Received on Saturday, 16 February 2013 00:07:26 UTC