really impressive, and thanks for the insight on how you achieved such good performance
On Apr 12, 4:25 am, 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/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
