Intent to Ship: Image Capture API

[Owen]

Contact emails

mca...@chromium.org, owe...@chromium.org

Spec

Image Capture

Summary

Image Capture enables taking pictures from an Image/Video Capture Device and controlling photo-related capabilities.

TAG reviewed the W3C Image Capture Spec (here), a couple of interop issues were pointed out between the API form and other neighboring APIs. We worked with Mozilla to update the spec, essentially moving the ways to get/set the photo capabilities/settings (PR) from the ImageCapture object to the feeding MediaStreamTrack. This guide documents the change and how to migrate for those that have written code based on the old version.

These TAG updates happened in parallel to the Origin Trial experiment which begun in M56 (blog post, Android Police) and will be available in 57 (now stable) and 58.

We have published an update based on the Origin Trial usage so far, but we haven’t yet heard feedback through that as we’re only 6 weeks in and token renewals haven’t yet started.

It is our belief the the content and shape of the Spec is now ready for shipping so we propose to ship in 59 while continually monitoring the OT feedback for red flags, and changing course only if something comes up in developer feedback.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/WYTiG9h8Xbs

Link to "Intent to Experiment" and "Origin Trial Results"

I2E: https://groups.google.com/a/chromium.org/d/msg/blink-dev/iAIKruoq5QM/Ht0eD081AwAJ

OTR: https://groups.google.com/a/chromium.org/d/msg/blink-dev/tQNJOJIMgqA/y6XBgU-cCgAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://simpl.info/imagecapture/

https://rawgit.com/Miguelao/demos/master/imagecapture.html

https://rawgit.com/Miguelao/demos/master/imagecapture2.html <-- In progress comprehensive demo.

Interoperability and Compatibility Risk

Firefox: In development.  Signed off all and any changes to the Spec.

Edge: No public signals

Safari: No public signals

Web developers: Positive

Firefox has released a partial implementation and we believe their support on the spec makes this low compatibility risk.

OWP launch tracking bug

https://crbug.com/603328

Entry on the feature dashboard

https://www.chromestatus.com/features/4843864737185792

[PhistucK]

On Tue, Mar 28, 2017 at 4:02 AM, Owen <owe...@chromium.org> wrote:

Firefox has released a partial implementation

​Care to share more details about this? Does "released" mean "shipped"? Which part did they (release or) ship​?

☆PhistucK

[Miguel Casas-Sanchez]

The Spec's implementation status has more details: Firefox has implemented the zero-shutter grabFrame() method, it seems to be behind a flag.

[Philip Jägenstedt]

As recently promised, I will go ahead and ask about an interoperability test suite, i.e. web-platform-tests. By searching for the API names, it looks like there isn't anything in wpt currently, is that right? Shipping will not be blocked on additional testing work, but some bugs to track the eventual existence of full test suite in wpt would be great to have.

Looking for things we might regret, in https://github.com/w3c/mediacapture-image/issues I see 2 open renaming issues. Those would end up wontfix by shipping, so can they be resolved first to be upfront about that?

[Miguel Casas-Sanchez]

On 29 March 2017 at 08:19, Philip Jägenstedt <foo...@chromium.org> wrote:

As recently promised, I will go ahead and ask about an interoperability test suite, i.e. web-platform-tests. By searching for the API names, it looks like there isn't anything in wpt currently, is that right? Shipping will not be blocked on additional testing work, but some bugs to track the eventual existence of full test suite in wpt would be great to have.

 

Correct.  Regarding the tests, LayoutTests/fast/imagecapture has a few entries but, given the nature of the implementation (that talks to a mojo interface), they are very reduced, mostly checking that methods exist, Promises are rejected and Exceptions are thrown.  LayoutTests/imagecapture, OTOH, are beefier and interact with a mock mojo implementation where we, e.g. configure photo settings and read them back, etc.  

The first set could be upstreamed in a jiffie; what can we do about the second, any ideas?

Also made https://crbug.com/706434 so we won't forget.

 

Looking for things we might regret, in https://github.com/w3c/mediacapture-image/issues I see 2 open renaming issues. Those would end up wontfix by shipping, so can they be resolved first to be upfront about that?

Yeah, issue #106 does not apply anymore and should be closed. #88 has no consensus on the alternative name for takePhoto() method (alternatives are e.g. capture(), captureImage() and takePicture()), chances are that we'll leave it as-is. Let me ping François to see if we can close them.

[Giovanni Ortuño]

On Thu, Mar 30, 2017 at 3:36 AM Miguel Casas-Sanchez <mca...@chromium.org> wrote:

On 29 March 2017 at 08:19, Philip Jägenstedt <foo...@chromium.org> wrote:

As recently promised, I will go ahead and ask about an interoperability test suite, i.e. web-platform-tests. By searching for the API names, it looks like there isn't anything in wpt currently, is that right? Shipping will not be blocked on additional testing work, but some bugs to track the eventual existence of full test suite in wpt would be great to have.

 

Correct.  Regarding the tests, LayoutTests/fast/imagecapture has a few entries but, given the nature of the implementation (that talks to a mojo interface), they are very reduced, mostly checking that methods exist, Promises are rejected and Exceptions are thrown.  LayoutTests/imagecapture, OTOH, are beefier and interact with a mock mojo implementation where we, e.g. configure photo settings and read them back, etc.  

The first set could be upstreamed in a jiffie; what can we do about the second, any ideas?

We are working on a path to upstreaming tests that use Mojo: https://groups.google.com/a/chromium.org/d/msg/platform-predictability/kSntsq9vgjY/3TaKZJFRAgAJ

[Philip Jägenstedt]

On Thu, Mar 30, 2017 at 1:36 AM Miguel Casas-Sanchez <mca...@chromium.org> wrote:

On 29 March 2017 at 08:19, Philip Jägenstedt <foo...@chromium.org> wrote:

As recently promised, I will go ahead and ask about an interoperability test suite, i.e. web-platform-tests. By searching for the API names, it looks like there isn't anything in wpt currently, is that right? Shipping will not be blocked on additional testing work, but some bugs to track the eventual existence of full test suite in wpt would be great to have.

 

Correct.  Regarding the tests, LayoutTests/fast/imagecapture has a few entries but, given the nature of the implementation (that talks to a mojo interface), they are very reduced, mostly checking that methods exist, Promises are rejected and Exceptions are thrown.  LayoutTests/imagecapture, OTOH, are beefier and interact with a mock mojo implementation where we, e.g. configure photo settings and read them back, etc.  

The first set could be upstreamed in a jiffie; what can we do about the second, any ideas?

Also made https://crbug.com/706434 so we won't forget.

Thanks, that looks good!

Looking for things we might regret, in https://github.com/w3c/mediacapture-image/issues I see 2 open renaming issues. Those would end up wontfix by shipping, so can they be resolved first to be upfront about that?

Yeah, issue #106 does not apply anymore and should be closed. #88 has no consensus on the alternative name for takePhoto() method (alternatives are e.g. capture(), captureImage() and takePicture()), chances are that we'll leave it as-is. Let me ping François to see if we can close them.

I've commented on #88 that we won't block on that, you should ship with whatever name you like best.

LGTM1

[Rick Byers]

On Thu, Mar 30, 2017 at 9:36 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Thu, Mar 30, 2017 at 1:36 AM Miguel Casas-Sanchez <mca...@chromium.org> wrote:

On 29 March 2017 at 08:19, Philip Jägenstedt <foo...@chromium.org> wrote:

As recently promised, I will go ahead and ask about an interoperability test suite, i.e. web-platform-tests. By searching for the API names, it looks like there isn't anything in wpt currently, is that right? Shipping will not be blocked on additional testing work, but some bugs to track the eventual existence of full test suite in wpt would be great to have.

 

Correct.  Regarding the tests, LayoutTests/fast/imagecapture has a few entries but, given the nature of the implementation (that talks to a mojo interface), they are very reduced, mostly checking that methods exist, Promises are rejected and Exceptions are thrown.  LayoutTests/imagecapture, OTOH, are beefier and interact with a mock mojo implementation where we, e.g. configure photo settings and read them back, etc.  

The first set could be upstreamed in a jiffie; what can we do about the second, any ideas?

Also made https://crbug.com/706434 so we won't forget.

Thanks, that looks good!

Thanks!  As far as I'm concerned, the priority here should be for things which can already be tested only with standard APIs (idlharness).  There's a lot of technical and non-technical issues to work out generally for interop testing of things that require automation/mocking .

Looking for things we might regret, in https://github.com/w3c/mediacapture-image/issues I see 2 open renaming issues. Those would end up wontfix by shipping, so can they be resolved first to be upfront about that?

Yeah, issue #106 does not apply anymore and should be closed. #88 has no consensus on the alternative name for takePhoto() method (alternatives are e.g. capture(), captureImage() and takePicture()), chances are that we'll leave it as-is. Let me ping François to see if we can close them.

I've commented on #88 that we won't block on that, you should ship with whatever name you like best.

LGTM1

LGTM2 

[Dimitri Glazkov]

LGTM3