Re: New Editor's Draft of MediaStream Image Capture

On Mon, Oct 20, 2014 at 4:39 PM, Mandyam, Giridhar <mandyam@quicinc.com>
wrote:

>  Ø  Aren't the possible MIME types returned exactly the same for both
> takePhoto() and grabFrame() --- any kind of still image format?
>
>
>
> MIME types was misleading – my apologies.  takePhoto() should return
> compressed formats like JPG or GIF (Blob w/associated MIME type).
> grabFrame() would return an ImageData() object.
>
Ø  Can you clarify somewhere which PhotoSettings are honoured by
> grabFrame()? Is the answer "none"?
>
>
>
> My assumption is that all of the settings would be honored by both
> methods.  I can clarify in the text.
>

Hmm. It seems to me that flash settings, at least, would not be honored by
grabFrame() since grabFrame() does not have this language that takePhoto()
has: "Devices may temporarily stop streaming data, reconfigure themselves
with the appropriate photo settings, take the photo, and then resume
streaming."

So the differences between grabFrame() and takePhoto() are:
1) takePhoto() allows that stop-streaming-and-reconfigure behavior, but
grabFrame() does not. Thus, certain features like flash won't work with
grabFrame().
2) takePhoto() produces a Blob in some compressed image format and
grabFrame() produces an ImageData.
Is that right?

What is the rationale for difference #2? Would it make sense to separate
these concerns and allow either API to return an ImageData or a Blob?
Actually I'm not sure ImageData is the right thing here, since it may force
reading data into main memory and/or converting it to RGB even for use
cases where that's not needed. I think returning an ImageBitmap would make
more sense:
https://html.spec.whatwg.org/multipage/webappapis.html#images
Perhaps we could make both takePhoto() and grabFrame() return an
ImageBitmap?

  Ø  I don't think 'onoptions' is needed. Most Web APIs don't have features
> like this.
>
>
>
> I kept this in there because the photo settings could change due to end
> user intervention at any time (like on many  devices with integrated
> cameras).
>

You mean that there is some kind of dedicated user interface --- e.g.
hardware buttons --- that can directly override the camera settings, even
while an application is trying to use the camera, in a way that the
application can't prevent? That sounds problematic from the application
developer's point of view. Seems to me a better design would to have those
hardware controls fire DOM events that are described in some spec and which
the application can block the default action of using preventDefault().

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.