RE: New Editor's Draft of MediaStream Image Capture

Roc,

Thanks for the feedback.  My apologies for not addressing this earlier.  I am trying to address the outstanding comments at one go.  Please also feel free for you or anyone else in your org to file issues on the gh repo: . https://github.com/w3c/mediacapture-image/issues.



Ø  In the PhotoSettings WebIDL, I think autoExposureMode should be declared ExposureModeEnum instead of 'any'..  ExposureModeEnum should just be called ExposureMode.
OK – will address in the next revision.

Ø  The duplication between PhotoSettings and PhotoOptions is unfortunate. Especially because ImageCapture.setOptions takes a PhotoSettings not a PhotoOptions! I think it would be simpler to get rid of PhotoOptions and make all its attributes be direct (read/write) attributes of the ImageCapture object. Then PhotoSettings would just be a way to expose the capabilities of the device, so we could rename it to PhotoCapabilities and simplify it a bit.

Personally I'd just eliminate PhotoCapabilities too and add readonly attributes directly to MediaCapture like brightnessMin/brightnessMax. Or, for values (like brightness) that aren't on a specified scale anyway, simply say that 0 is min brightness and 1 is max brightness.
Changing PhotoOptions to PhotoCapabilities is not a problem, and seems to make good sense.  Eliminating this object altogether in favor of individual readonly attributes is possible, but then I think the issue boils down to a matter of personal taste.  From my perspective as a spec editor, this is mainly an issue of readability of the spec as the desired functionality is retained with either approach.  However, you certainly have more insight than myself as to what would be the typical web developer preference for such a feature.  Would they prefer to have device capabilities accessible as a readonly object (PhotoCapabilities), or as individual readonly attributes?


Ø  There's a typo in the PhotoSettings and PhotoOptions WebIDL: "constrast".

Ø  Shouldn't PhotoSettings contain "zoom"?
Yes.  Will correct.


Ø  The difference between grabFrame and takePhoto is quite subtle. Would it make sense to only have one method and event handler, and add an option that specifies whether to just grab a frame or go to the effort of taking a still shot?

I was trying to avoid introducing unnecessary ambiguity, so two different methods were defined for the two possible photo capture events that could be raised by the capture device.   Depending on the method invoked by the developer, there is a clear understanding of the possible MIME types of the returned data.  It is possible to collapse this into a single method with an argument to set the option for capture – I am not sure what to call that method as takePhoto() may not be appropriate.

-Giri

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Thursday, September 04, 2014 5:28 PM
To: Mandyam, Giridhar
Cc: public-media-capture@w3.org
Subject: Re: New Editor's Draft of MediaStream Image Capture

In the PhotoSettings WebIDL, I think autoExposureMode should be declared ExposureModeEnum instead of 'any'.
ExposureModeEnum should just be called ExposureMode.
The duplication between PhotoSettings and PhotoOptions is unfortunate. Especially because ImageCapture.setOptions takes a PhotoSettings not a PhotoOptions! I think it would be simpler to get rid of PhotoOptions and make all its attributes be direct (read/write) attributes of the ImageCapture object. Then PhotoSettings would just be a way to expose the capabilities of the device, so we could rename it to PhotoCapabilities and simplify it a bit.

Personally I'd just eliminate PhotoCapabilities too and add readonly attributes directly to MediaCapture like brightnessMin/brightnessMax. Or, for values (like brightness) that aren't on a specified scale anyway, simply say that 0 is min brightness and 1 is max brightness.
There's a typo in the PhotoSettings and PhotoOptions WebIDL: "constrast".
Shouldn't PhotoSettings contain "zoom"?
The difference between grabFrame and takePhoto is quite subtle. Would it make sense to only have one method and event handler, and add an option that specifies whether to just grab a frame or go to the effort of taking a still shot?

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo
otohoeo ofoioroeo ooofo ohoeololo.