RE: Drop work on DAP charter v3?

More on the functions that are currently challenging with getUserMedia+JavaScript approaches to barcode scanning, in addition to autofocus:
- macro mode (related to ability to focus)
- auto flashlight: when it's dark, we need to be able to control the camera flashlight to make it possible to resolve a code. This needs to occur automatically or under control of the app.
- resolution of all code types: commercial grade code readers are capable of resolving more code types (at least currently)
- reliability: commercial grade code readers have high reliability - comparatively, open-source nature code resolution libraries may not be as fully implemented or tested

These issues can affect the public's perception of barcode reading apps. The last two may be addressed over time, but at least the first two probably need specific support in any API used for barcode scanning. If all we have though is the simple ability to attach the camera feed to a video element and read the data off a canvas, this may not be enough for reliable operation. In devices which support dedicated (native) code reader apps, it should still be possible for the user to fall back to use of those apps if Web-based readers fail (though this is not a good user experience). But in Web-based devices (with little or no native app support), it will be important to provide a more robust ability to read barcodes.

So overall, while I agree that DAP rechartering probably isn't worthwhile for one API, I still think there is value in either:
- in Media Capture TF: beefing up getUserMedia to add options to control autofocus, macro mode, and flash
- in DAP or another WG (Sysapps?): defining a specific API for barcode scanning

Thanks,
Bryan Sullivan 

-----Original Message-----
From: SULLIVAN, BRYAN L 
Sent: Wednesday, May 23, 2012 9:26 AM
To: 'Rich Tibbett'
Cc: Robin Berjon; public-device-apis@w3.org public-device-apis@w3.org
Subject: RE: Drop work on DAP charter v3?

Rich,

Can you drop a URL to the Opera Mobile Next release? All I can find on this is Opera Mini Next. 

The main issues I had were reported to Opera, based upon the Opera Labs Camera release. I have not tested any other browser as AFAIK only Opera supports getUserMedia (at least on mobile, which is where I was interested in testing it).

As to the functions that can't be implemented in JavaScript, I will need to check with our barcode experts and get back to you.

I agree that if it works reliably just through JavaScript, then we can put a fork in it, and move on to other things. But my experience tells me we're not there yet.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Wednesday, May 23, 2012 3:49 AM
To: SULLIVAN, BRYAN L
Cc: Robin Berjon; public-device-apis@w3.org public-device-apis@w3.org
Subject: Re: Drop work on DAP charter v3?

SULLIVAN, BRYAN L wrote:
> I've tried out the Javascript QR code reader demos and it's true they kind of work sometimes on laptops, but so far I have not been able to get them to work on mobile phones.

It seems this is due to the lack of timely autofocus you mention below? 
Or do you think there are other issues that prevent capturing QR codes 
on mobile? Interested to hear about your experiments in this area.

> There are various complexities (e.g. Autofocus) that don't work well in current getUserMedia implementations for example,

We recently patched our getUserMedia implementation to autofocus a media 
stream against the current scene every X seconds. X is currently set at 
10 but we're going to continue experimenting with that number. That 
should fix the autofocus problem and make QR code reading more accurate. 
It should already be available in current Opera.Next Desktop/Mobile 
releases.

> beyond that there are code translation functions that can't be delegated to JavaScript alone (at least for indirect codes), etc.

What functions did you have in mind that can't be implemented in JavaScript?

> For these reasons it is beneficial to have an API that can invoke a local code reader client which has been designed specifically for those functions. I am currently involved in discussions in the OMA on the requirements for such a Web Runtime API, and possible design approaches to integrate it with a HTML5 browser based UI. I would like to bring that discussion into W3C as soon as possible, so would appreciate the QR code reader API to be considered in DAP or the System Level API WG charter.

In the mean time it seems like we should experiment in JavaScript and 
are likely to require JS shims/fallbacks using getUserMedia for 
unsupported browsers in the short/medium term. Perhaps indefinitely.

--

Our QR code reader proof-of-concept implementation can be seen @ 
http://www.shinydemos.com/qr-code/. We're getting fairly close to doing 
everything we need to do wrt QR code capture without requiring a 
dedicated API.

- Rich

[1]

Received on Saturday, 26 May 2012 13:56:37 UTC