|
From: Simon P. <S.G...@ba...> - 2010-01-08 21:29:48
|
Hi Mike, > Thanks for your message, and for mbarcode! No probs, thanks to you chaps for some cool decoder sw. :) > That's a good question. When left untuned, libdmtx can bog > down under certain image conditions. There are plans in the > works to overhaul the relevant code, but for now the best > thing is to identify and correct the problem through tuning > parameters. Is it possible for you to send some sample > images, and problematic ones in particular? We might be able > to help out. The issue seems to be running the decoder full stop, not any particular image to be decoded. I get a stutter whenever the decoder is run, not when it's decoding some particular Datamatrix barcode (e.g. in mbarcode iirc I run the dmtx decoder in a thread 2x per second while the Zbar decoder runs in another thread ~10x per second, and I get momentary stutters whenever the dmtx decoder is run). Could you point out the relevant code? Also, has any work been done on an integer-only decoder (as fp operations are relatively expensive on "embedded" devices and might be having an impact here)? > I don't see any reason that we can't ultimately be every bit > as fast as QR Code. :) Great! :) > I recommend checking out the page at > http://libdmtx.wikidot.com/helpful-tips for a brief > description of some tuning parameters as they relate to > libdmtx itself (i.e., not necessarily the Gstreamer module) Thanks. > You can also refer to the man page for dmtxread (availble > online at http://libdmtx.org/display.php?text=dmtxread.1) > > I briefly looked at the gst-dmtx code and it appears that > "skip" is related to frame rate (as in "only pay attention to Yeah sorry, I though that was something passed straight to dmtx, my mistake (having since looked at the source for both the library and the gst element in detail). > every 30th frame in this stream), whereas "scale=2" does in > fact relate to the "shrink" option in libdmtx "proper". If > you are already working with small-ish images (320x240) then > the "scale=2" option probably won't help your performance, > and in fact will probably hurt the scan reliability. Ok, well at least I know to not bother with that one. > I hope this helps. I'm looking forward to seeing some example > images so we can improve the tuning. I think my next step is probably to compile whatever command line tool comes with libdmtx and use that to benchmark the decoder on the N900 using various parameters and see if I can speed things up. After that, improvements to the code (possibly ARM specific) are probably the best bet, so any pointers to known bottlenecks/issues would be appreciated to I know where to start looking. Many thanks, Simon |