Re: New mBarcode release on its way
 

Sorry, you were right about the update.
Thanks :)

Re: New mBarcode release on its way
 

Is it possible to get support to microsoft tag also: http://tag.microsoft.com/consumer/index.aspx

Re: New mBarcode release on its way
 

There are two possibilities - see if the authors of either libdmtx or libzbar are looking to add decoders for this type of barcode (as these are what we use at the backend) or if there's an open-source decoder lurking somewhere I can plumb it in assuming it doesn't require too much CPU and screw everything else up ;)

Re: New mBarcode release on its way
 

Just like goddamn microsoft to go their own way with a proprietary format.

Re: New mBarcode release on its way
 

Maybe through a collaboration with the lfocus developer.

Re: New mBarcode release on its way
 

Hi

I have noticed that it sometimes fails to recognise 2D barcodes even when absolutely crystal clear with perfect lighting/contrast - rotating the camera or subject sometimes helps but not always, anyway , just as i'm about to give up and move the camera away it suddenly seems to recognise it, and from a really blurred mess of an image which i really struggle to believe it could decipher anything from, yet the code is correct.

Is it possible that it has previously recognised it but failed to notify the gui somehow and that when it becomes so blurred it really cant tell what it is that it gives up it then shows the code along side a messy image.

Is the image shown definitely the one the code was derived from? - if so its pretty incredible what it can do!

Re: New mBarcode release on its way
 

There shouldn't be any way for the decoder to decode something and the UI not be told, so the problem is not there.

What might be happening is that the pipeline is forked, where the camera itself it at the root and one branch goes off to display on the screen, and the other is piped through the libzbar and libdmtx decoders (implemented as gstreamer elements) one after the other.

Now the framerate is higher than the decoder rate, so some of the frames displayed on the display branch will simply be dropped by the decoder branch until the decoders have finished processing their current frame.

So to answer that question, no, the frame shown is not necessarily the one decoded, but there shouldn't be much lag (though there is more lag on dmtx than on QR codes as the libdmtx decoder is slower).

Speaking about decoding from blurry images, the QR code decoder really is rather good at this, better than the 1D code decoder certainly.

Re: New mBarcode release on its way
 

I'm actually seeing this myself from time to time. When I think about it, this might be a problem caused by the constant autofocusing, although I remember having seen this some time ago as well. Maybe we should wait until the previous image has been decoded before calling autofocus again, just to make sure it does not get called again and again when the autofocus is temporarily causing the image to be out of focus?

Or would it be better to wait for the autofocus' success signal before calling the decoders at all? A simple way would be to set a "bool readyForDecode" to true whenever the autofocus callback returns with success and to false whenever autofocus is initiated?

Re: New mBarcode release on its way
 

If you already know what the product is (ie you have it in front of you) why would you need this app to find out what it is?
I'm not knocking it as a fair number find it useful but I am not sure of it's use

Re: New mBarcode release on its way
 

There are several good ways to use the barcode: Automatically start a search where the article can be bought next to your location with less price. Search online stores, find similar articles "is this available in another color?".

Also the QR-code can be used for many things. Urls, VCards, maybe some time for our ovi store (like android does).