Recommendation for app using front-facing camera

[Sean Owen]

(I moderated this message, but it never turned up. Posting on behalf of the original sender.)

I'm developing a kiosk application with QR scanning capability on a Nexus 7, which only has a front-facing camera. I'd be happy to use ZXing's BarcodeScanner app externally via Intents, but it doesn't support front-facing cameras. I can easily patch the ZXing trunk to support a front-facing camera (attached), now that it's switched to GingerbreadOpenCameraInterface, but distributing a patched version of the BarcodeScanner app really isn't the right way to do it.

I thought of including the android client code as a library within my app, but reading around I see many other people had the same idea, and that the ZXing project strongly recommends against this approach, and doesn't support the code being used that way.

So, that leaves me with a third option of writing a client app from scratch on top of the ZXing core.jar. A scan with SLOCCount--on just the Android client, not even including the core and iPhone, and other code in the repo--leads me to suspect this will be a massive undertaking:

Totals grouped by language (dominant language first):
java:          6143 (56.58%)
xml:           4715 (43.42%)

Total Physical Source Lines of Code (SLOC)                = 10,858
Development Effort Estimate, Person-Years (Person-Months) = 2.45 (29.36)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.75 (9.03)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 3.25
Total Estimated Cost to Develop                           = $ 330,506

I looked at androidtest as a simple example (~600 lines of java, ~200 lines of xml), but since it is a basic test (as intended), it can't currently support front-facing cameras. Dropping support for front-facing cameras isn't an option at this point, and I haven't found any other QR code scanning software for Android that's anywhere near as good as ZXing. Do you have any suggestions on the best way to approach this?

Thanks,
Allison

[Steven Parkes]

On Sep 6, 2012, at 2:07 PM, Sean Owen <sro...@gmail.com> wrote:

> (I moderated this message, but it never turned up. Posting on behalf of the original sender.)

I saw it.

[Sean Owen]

Yes, really the only change that's necessary is making it not require a camera, which means rear camera. The code will already choose the only camera, the front-facing one, if that is the only one available.

The next release would have this change. Daniel are you OK with changing the requirements this way to let the Nexus 7 use it? I guess it needs one more code path to throw an error on devices that really don't have any camera.

You can wait for that. You can also use https://play.google.com/store/apps/details?id=com.srowen.bs.android which has this change already, if that's feasible.

You can also incorporate scanning in your own code. What is discouraged is wholesale copying, including the UI and manifest, such that it's mostly a clone plus tweaks, versus an app that happens to integrate scanning on the side. You can't swing a stick on Play without finding a modified Barcode Scanner that sends you to some e-commerce site via affiliate links, with ads, etc.

Building from scratch is a lot harder than integrating some pieces. I think it's weeks of work, not years.

[Allison Randal]

It's certainly easiest to wait for a new release of the BarcodeScanner
app that supports front-facing cameras. It partly depends on when that
release might be. It's worth waiting a few weeks to save a few weeks of
development work, but not worth waiting a few months or a year.

It looks like that alternate BarcodeScanner+ app is paid? I don't think
we'll be able to sell our clients on paying for a barcode scanner to go
with our free app. (It's already a paid service, so they can reasonably
expect the apps to access it will be free.) So, not a long-term
solution, but would be fine to use it in development while waiting for a
new version of the regular BarcodeScanner app.


On integrating some pieces, I had the impression that you didn't want
other apps to reuse any code at all from the android/ directory? Which
pieces would you recommend integrating and which would you recommend
rewriting?

Thanks,
Allison

[Sean Owen]

Daniel has the release keys -- do you have time for a 4.3 release soon? I think there's a minimum but sufficient set of changes / improvements / time elapsed since 4.2 to make it worthwhile.

Yes a for-pay app is probably only useful for the short-term or limited testing.

Reuse is fine and encouraged. Copying completely feels wrong, and copying this sort of project wholesale presents particular problems -- customer confusion from cloning the UI, and Intent inteference from copying the manifest. I think that if you start by copying that app and modify from there you'll probably end up on the wrong side of these issues. If you are starting from your own app and intelligently reusing bits, almost surely fine. But that's why I have spoken out against tutorials on the topic of how to copy and paste the app into another app.

A new release is the best answer of course.

[Sean Owen]

The code already will choose a front camera if no rear camera exists. You can modify it further to prefer a front camera -- up to you to read the source though. Front cameras don't work well in general though.

[Domnic Savio]

On Tuesday, 23 October 2012 21:28:08 UTC+2, Sean Owen wrote:

The code already will choose a front camera if no rear camera exists. You can modify it further to prefer a front camera -- up to you to read the source though. Front cameras don't work well in general though.

Hi Sean,
I need to get the scanned barcode and then process it further..with additional data in my app which I am currently developing..I need to post a purchase order based on this scanned barcode from my app. Can you please let me know.. How I can include your BS+ as a library and use it ?

thanks
Domnic

[Sean Owen]

Like I said, it's pretty easy to make it *only* access the front camera if that's what you want -- just look at the source. You can use that as a template for building your app. BS+ is not an SDK per se, but you can itnegrate with it by Intent. You won't get the image data back though.

[Domnic Savio]

On Tuesday, 23 October 2012 22:07:54 UTC+2, Sean Owen wrote:

Like I said, it's pretty easy to make it *only* access the front camera if that's what you want -- just look at the source. 

You mean source for the Barcode Scanner..?
http://code.google.com/p/zxing/source/browse/trunk


or there is a seperate link for source in BS+ ?`!

thank you

[Domnic Savio]

On Tuesday, 23 October 2012 22:07:54 UTC+2, Sean Owen wrote:

Like I said, it's pretty easy to make it *only* access the front camera if that's what you want -- just look at the source.

I tried the
http://code.google.com/p/zxing/source/browse/trunk/android/src/com/google/zxing/client/android/camera/CameraConfigurationManager.java  

and the

http://code.google.com/p/zxing/source/browse/trunk/android/src/com/google/zxing/client/android/camera/CameraManager.java

is there a specific class I am over looked Sean ?

 

[Sean Owen]

Look at GingerbreadOpenCameraInterface

[Sean Owen]

The image data sent to an app is not flipped -- or at least, it should not be according to the API. I know some buggy devices fail to do so, and send flipped data. In that case you have to hack around it by flipping over the image data. See my earlier post on this topic today.

[Domnic Savio]

On Tuesday, 23 October 2012 22:48:40 UTC+2, Sean Owen wrote:

Look at GingerbreadOpenCameraInterface

Hi Sean,
Thanks for that. it works now. I can scan and get results. This is more than enough for the moment. I really appreciate your help there.
cheers
Domnic

[Ron Yust]

Now I'm confused.  Sean, are you saying zxing can read and decode a mirror image barcode (QR code)?  Using a device like the Nexus 7 shows the preview barcode image flipped on the SurfaceView so I assumed there was code in zxing to flip it back so it could be scanned correctly.  What am I missing here in my understanding?

[Sean Owen]

The correct behavior from a device's front camera is to:

• Send the image data un-flipped (as it sees it, facing you) to an app processing preview frame data, but
• Flip the image data before flinging it onto a SurfaceView, because a mirror-image is more intuitive for the user facing the display

A mirror-image of a barcode is not necessarily valid. It doesn't matter for, say, UPC-A, but a mirror image QR code is not valid. No, the library does not spend CPU cycles trying the reversed image for this reason.

The data from the camera is never (supposed to be) flipped, so there also isn't anything to un-flip fortunately.

I know a few devices send the flipped data to the app, but that's just a bug in the device.

[Jade Byfield]

Did this work for your needs? I modified the source code of the client to use the front camera, but never get anything to scan, and after looking around I've read that it's because front cameras not only have very low resolution, but they also lack autofocus. I'm just curious on what/how you were able to get something working for your Kiosk. Hope to get a response from you

[Bas Vijfwinkel]

Here in Japan I came across some shops which had barcode scanners attached to Android tablets.
You could do the same with a usb normal webcam.
If you tablet will be in a custom case you could mount the a camera + additional light sources behind a glass panel to ensure that both the distance and lightning is optimal. Our local 24h gas stations use the same technique for coupons and other stuff.

[Jade Byfield]

Thanks for your suggestion Bas! I was thinking of something similar, but I wasn't sure how I would go about making the relationship between the usb cam and the zxing source code. How hard would that be? If I attached a USB camera to my android tablet, how would I go about getting zxing(and the tablet) to recognize that this is the camera I want to use for the scanning?

I also love the part about mounting everything in a custom case, so it looks flushed and as it were designed purposefully(which it will be). Hope my question makes sense, thanks again for your feedback!