- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Mon, 20 Oct 2014 21:48:22 +1300
- To: "Mandyam, Giridhar" <mandyam@quicinc.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CAOp6jLaKP=qS_fS0cE_LxgCiGd5CmAv2WQHu+fwob1O+eWHyug@mail.gmail.com>
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.
Received on Monday, 20 October 2014 08:48:51 UTC