That's unlucky... I've made similar mistakes and have learned some lessons, one of which is to always test the real thing with real data as soon as possible, that's why the first thing I wrote for android were my camera source classes. The only quick win for convolution is probably reducing the kernel size, or perhaps you can optimize for the specific kernel?
On Apr 12, 12:39 pm, qvark <[EMAIL PROTECTED]> wrote: > Thanks Tom for your comments! > > As I supposed, there is not a magic spell but a careful algorithm > choice and a lot of optimization work... I was also worried with the > possible performance of my algorithms, so I started a proof of concept > to see if they were viable. Unfortunately, I tested them outside the > emulator and I made the assumption (how wrong!) that the performance > was going to be similar since them were going to run on the same > machine. Just a few days ago I integrated them with the Android UI and > I realized I had a big problem... > > Anyway, I will try to do my best in these last days and I will submit > my application because I think at leas the idea is not bad :) > > Good luck again! > > On 12 abr, 12:25, 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 -~----------~----~----~----~------~----~------~--~---
