Wednesday, December 9th, 2009

W3C Capture API our in draft

Category: Standards, W3C

<p>A draft of the W3C Capture API has been put out there by the editors.

The Capture API defines a JavaScript API for accessing the microphone and camera of a hosting device.

When I look at the API for getting pictures from a camera I got a little scared at the amount of DOM fluff around the edges:

javascript
< view plain text >
  1. // Create a container div element and append it to the document body.
  2. var container = document.createElement("div");
  3. document.body.appendChild(container);
  4.  
  5. // The browser viewport width in pixels.
  6. var screenWidth = window.innerWidth;
  7.  
  8. function successCallback(data) {
  9.   for (var i in data) {
  10.   var img = document.createElement("img");
  11.   img.src = data[i].uri;
  12.   // If the image width exceeds that of the browser viewport, the image
  13.   // is scaled to fit the screen keeping the aspect ratio intact.
  14.     if (data[i].format.width > screenWidth) {
  15.       img.style.width = screenWidth + "px";
  16.       img.style.height = (data[i].format.height/data[i].format.width)*screenWidth + "px";
  17.     }
  18.     container.appendChild(img);
  19.   }
  20. }
  21.  
  22. function errorCallback(err) {
  23.   alert(err.message + " (" + err.code + ")");
  24. }
  25.  
  26. // Launch the device camera application and invoke the callback once
  27. // the user exits the camera application.
  28. transactionId = navigator.device.captureImage(successCallback, 1, errorCallback);

A lot of fluff for the transactionId = navigator.device.captureImage(successCallback, 1, errorCallback); meat.

What do you think of the API proposed?

Related Content:

12 Comments »

Comments feed TrackBack URI

Well, it looks like the “fluff” is just part of the example, so it can display the captured image in a DIV. You wouldn’t necessarily need that in a real-world situation.

Comment by JW123 — December 9, 2009

I like the API, though I want to make sure that the camera and microphone access is opt-in like it is with flash. Any application that requests access to the camera or microphone should automatically force the user to accept that access.

Is this written into the specification?

Comment by blister — December 9, 2009

I was making a JS port of a optical-touch related project of mine ( http://shinytouch.googlecode.com ), and I used with to access the pixel data. I would have thought that it would have been something like a special URL like device://camera in the src field of a , but I guess that isn’t quite capable of everything that a device would need (like adjusting the camera resolution, focus, etc).

Comment by antimatter15 — December 9, 2009

I think it’s really strange to have 2 different callbacks.. (never seen it anywhere else) I think it would be better if it work like this:
navigator.device.captureImage(callbackFn, [limit]);
and callback always returning an object with the “status” property (success/error).
I think limit should also be optional and default to 1 (or maybe “infinite”).

Comment by millermedeiros — December 9, 2009

It’s be nice to have frequency and waveform data for captured audio like flash does, but I guess if the raw data is there we can generate (some of?) that info from js via Fourier.

Comment by rdza — December 9, 2009

It looks nice and simple, but limited. I don’t see how it could be used for anything realtime, like video chat (although that’s mentioned in the Use Cases section of the document). It doesn’t give access to audio data, so you can’t analyze frequencies or audio levels. I guess you can get access to image pixels by drawing the image on a canvas though.

The capture API seems to be designed mainly for mobile devices. It would be nice with an API with more capabilities for more powerful devices, so Javascript can compete better with Flash.

Comment by vilcans — December 10, 2009

Most of this API is a confused, conflicting rewrite of the W3C File API, which has just been implemented in Firefox.

Instead of re-inventing the wheel with navigator.device.captureImage(), it should be an api on the HTML input element, which would allow you to use the proper W3C File API to examine the properties of the content you’ve created (and which is more semantic, and already has an attribute for mime-type). I would go for input.sensors.captureImage(), which would allow you to add additional sensors in future such as microphone, webcam, temperature, pressure etc.

Comment by chrisfjay — December 10, 2009

I would like to see API for capturing screenshots.

Comment by NikitaVasilyev — December 11, 2009

W3C Capture API ___our___ in draft. My eyes!!! On another note, I’ve been waiting for this draft for a long time. Will it be part of the HTML 5 specs?

Comment by olalonde — December 12, 2009

@blister: “… a conforming implementation of this specification must provide a mechanism that protects the user’s privacy and this mechanism should ensure that such operations must be authenticated.” That’s good!

I’m fine with the multiple callbacks (very common in JS frameworks) but typically they are referenced from an Object argument, not in multiple arguments with a Number argument separating them, that’s odd.

In many JS frameworks it looks something like: call({success : fn, error : fn});

Comment by richtaur — December 12, 2009

A few things ought to be clarified here:

First, this draft is internal to the working group. Since we work in public, it happens to be available for everyone to read, but it is not an official release in any way — you are looking at what is very, very much work in progress and the final thing might look very different.

Second, there is ongoing debate about the right approach to take to this on the mailing list: http://lists.w3.org/Archives/Public/public-device-apis/

Finally, given that it’s public, comments from any reader here are very much welcome. Simply send them to the above list. Topics of particular interest include whether to use an approach based on the input element, and whether to tackle embedding a viewfinder with live video (or the audio equivalent) as part of v1.

Comment by robinberjon — December 14, 2009

very intresting
thanks

Comment by Aphrodisiac — January 15, 2010

Leave a comment

You must be logged in to post a comment.