Re: Image Capture Proposal, third version

On Thu, Apr 4, 2013 at 12:45 PM, Mandyam, Giridhar <mandyam@quicinc.com>wrote:

>
> > I think to make life easy for authors the ImageCapture object should
> look as much as possible like MediaRecorder. I guess we can't reuse
> MediaRecorder (I know you just removed it from there, which I think was the
> right thing to do) but I think it would make sense to make the API match
> MediaRecorder as much as possible. For example, setPhotoSettings() should
> just be setOptions().****
>
> ** **
>
> A proposed goal for the group is to have all 3 specs (Recording, Media
> Capture & Streams, Image Capture) move away from settings to a
> constrainable interface.  Do you have an opinion as to the way constraints
> are currently defined in the Media Capture & Streams spec?
>

I'll look into constraints a bit later...

****
>
> > What's the use-case for the frameGrabber stuff? If it's real-time video
> processing, I think we need a completely different API that's based on Web
> Workers. I'll ignore the frameGrabber stuff for now.
>
> ** **
>
> It was decided during the last conf. call to remove this method.
>

Great :-)


> > For example, are multiple takePhoto() calls allowed? What happens if
> the author makes multiple takePhoto() calls?
>
> ** **
>
> If there are multiple invocations of the takePhoto() method that are
> spaced out insufficiently in time such that the image capture device is not
> ready to capture a fresh image, then the onphotoerror event handler should
> be invoked.  The current text stating “If the UA is unable to execute the
> takePhoto() method for any other reason, then the UA *must* fire a
> PhotoErrorEvent event at the ImageCapture object with a new PhotoError
> object whose code is set to PHOTO_ERROR.” was supposed to cover this
> requirement, but I can be more explicit in the text.
>

Please do, thanks.

****
>
> > There is no point in firing events synchronously to indicate the success
> or failure of methods such as setPhotoSettings. You can raise an exception
> instead if necessary.
>
> ** **
>
> Actually, I proposed an event handler onphotsettingschange to also
> indicate when photo settings were changed directly by the end user.  It
> wasn’t meant to just indicate the success/failure of a setPhotoSettings()
> call.
>

OK, please clarify that in the spec.

****
> >'whiteBalanceModeSetting' can just be "whiteBalance'. Instead of an enum
> which simply maps to Kelvin, why not make it an unsigned long in Kelvin and
> have the UA map that to the nearest value it supports?
>
> ** **
>
> Fine – I can change this in the next version. However, I believe this is
> consistent with this setting’s counterpart in native OS’s (e.g.
> http://developer.android.com/reference/android/hardware/Camera.Parameters.html)
> that do not provide Kelvin mappings.
>

I don't think being consistent with Android should be a goal if we have a
better alternative.

****
>
> >'contrast', 'brightness', 'exposureCompensation', 'iso', 'saturation',
> and 'sharpness' seem to be completely undefined. That's bad.
>
> ** **
>
> I can certainly add better definition than that which is currently in the
> spec.  I wanted to get some level of agreement on the settings currently
> proposed first.  I’ll address this in the next version.
>

It's hard to evaluate the settings without knowing what they mean :-).

****
>
> > Firing events synchronously to indicate success or failure of API calls
> seems unnecessary. If the call fails, throw an exception (or silently
> ignore). If it succeeds, do nothing. That's the general rule for Web APIs.
>
> ** **
>
> As mentioned before - I’d like to keep the API conventions consistent with
> the Recording API, which currently has an onerror event handler.  ****
>
> ** **
>
> When I survey other W3C specs regarding event targets, it is a mixed bag
> as to whether onerror/onsuccess event handlers are defined.  For instance,
> the current version of FileReader defines an onerror event handler (
> http://www.w3.org/TR/FileAPI/#dfn-onerror).
>

Sure, because it has async methods. You need error events for async
methods. But sync API calls should not throw error events generally.

 Thanks,
Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"