ImageCapture function/flow relationship for setOptions()

Hi Giri,

I also have a question about ImageCapture function/flow relationship for 
setOptions()

In the definitions of takePhoto() and grabFrame() it says:

    "Devices may temporarily stop streaming data, reconfigure themselves
    with the appropriate photo settings, take the photo, and then resume
    streaming."

And in Example 2 it shows:

    captureDevice.setOptions({
      redEyeReductionSetting:true
    }).then(
      captureDevice.takePhoto().then(
        showPicture(blob),
        function(error){
          alert("Failed to take photo");
        }
      )
    );

So it seems that you use setOptions() to set a Setting...but this 
doesn't get applied until either takePhoto() or grabFrame() is called.

So if I call setOptions() and then introspect the settings these won't 
be updated unless there's a takePhoto() or grabFrame() in between?
Are these additive? e.g. do multiple setOptions() combine together? Does 
takePhoto() and grabFrame() act like a commit and there's some sort of 
setOptions() buffer? Or does any setOptions() simply override any 
previous? You can see my confusion here.

Also, when I try to introspect the settings, this is where we really 
drift away from the Constrainable Pattern.

    photoCapabilities of type PhotoCapabilities, readonly
        Describes current photo settings

Here the narrative of the spec is saying photoCapabilities will return 
"Capabilities" (which I would expect was the "range" of options this 
device supports).

But it's definition says it's returning a description of the "current 
photo settings".

In fact the crossing over here between the "current photo settings" and 
the MediaSettings[Item|Range] intended to define possible ranges or 
values leaves me very confused.

How would I find the set of ImageCapture capabilities this track/device 
supports? And how does that differ from finding the values that have 
actually been set?

roBman

Received on Tuesday, 31 March 2015 19:24:30 UTC