Yes, the barcodes are scanned on every frame. I experimented with lots of different approaches along the lines you suggest (ie. locking on intermittently and then tracking). I ended up writing several different optical flow implementations - some were fast too, I ought to put them online.
Basically, the idea looks good on paper, but is fraught with difficulties for all sorts of reasons most of which are too involved to go into here. One that becomes particularly obvious when you actually implement it (if I was smarter, it might have been obvious before) is that if the 'partial tracking' is much faster than the 'full scan' you get a nasty pause every time you do the latter. If the two take the same amount of time, what's the point of having two algorithms? And using two threads is no good because latency means that by the time the 'full scan' has finished, if the 'partial tracking' is running faster, the results are too late to be useful. As I said, this is just one of the difficulties. Tom. On Apr 12, 8:12 pm, Peli <[EMAIL PROTECTED]> wrote: > Do you extract the bar-code information at every time-step? > Or do you only extract the sqare's positions (with the assumption that > they did not move too much since the last video frame) and only do an > extraction of the bar-code after each couple of time steps? > > Peli > > On Apr 12, 12:25 pm, tomgibara <[EMAIL PROTECTED]> wrote: > > > Thanks for the support! > > > I won't be keeping the details secret: Moseycode is designed to be as > > open as possible and I'm going to be open sourcing all the key parts > > of the system as opportunity arises. It's just that open-sourcing > > software takes more effort than just writing it, and I haven't had the > > time yet. I'd also prefer to change some of the code structure first. > > > I might write more about my approach as soon as I get some time free, > > but essentially: I started playing with the Android SDK as soon as it > > came out and it inspired the idea for Moseycode. After that I spent 2 > > weeks (very intensively) designing eight quite different systems for > > scanning and picked the fastest, then spent time refining it. So, one > > of the key reasons for the fact that the barcodes can be scanned so > > quickly is that the were selected in that way: I matched the symbology > > to the fastest algorithms. For other image processing tasks you > > generally won't be so lucky. > > > FWIW here are some details: > > Almost all iteration bounds are statically defined* > > All arrays are statically pre-defined > > All processing takes place in a single function > > > in that function: > > it does no object creation, > > it does no method calls, > > it does no floating point > > it does no integer divides > > except outside the critical code path > > > * to make it variable, I use a simple source processor that I wrote > > that makes multiple copies of the source with different standard > > dimensions. > > > Producing a working algorithm under those constraints is very hit and > > miss and takes a lot of time. The algorithm is (necessarily) simple, > > based on adaptive thresholding, marching squares followed by a number > > of heuristics. It also aggressively downsamples the image, to get good > > enough performance without compilation. I'm confident that the > > algorithm will respond well to JIT or AOT compilation, though there > > are still many possible improvements. > > > Finally, I did suggest some time ago that the inclusion of a > > convolution operator for image effects/processing might be a useful > > addition to the APIs. But as ever, there are lots of trade-offs (eg. > > usability, applicability etc). > > > Tom. > > > On Apr 12, 8:04 am, qvark <[EMAIL PROTECTED]> wrote: > > > > Hello Tom, congratulations for your app! I think it is a very original > > > one and I hope you will be one of the winners! > > > > I have learnt a lot from you with with the articles about how to > > > connect a real camera to the Android emulator camera device > > > (http://www.tomgibara.com/android/camera-source) and the series about > > > computer > > > vision (http://www.tomgibara.com/computer-vision/). I'm glad to see a > > > project that has got almost real time processing of the images! In my > > > project I'm working with still images (800x600) and every convolution > > > operation against them takes tens of seconds. Could you (if you were > > > so kind) give some hints about how do you got it? If you want to keep > > > the details secret I will understand... ;) > > > > Thanks in advance and good luck! > > > > Jose Luis. > > > > On 11 abr, 20:17, tomgibara <[EMAIL PROTECTED]> wrote: > > > > > Forgot to add, there are some screenshots too: > > > > >http://www.tomgibara.lz/android/moseycode/releases/-Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Challenge" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-challenge?hl=en -~----------~----~----~----~------~----~------~--~---
