Open mchehab opened 5 years ago
Funny enough, for QR, only 4 (integer) rotation angles got it wrong:
for i in qr-code.png; do for j in $(seq 1 359); do n=${i/.png/-$j.png}; convert -rotate $j $i ../rotated/$n;done; done
for i in ../rotated/*.png; do if [ "$(zbarimg $i 2>/dev/null)" != 'QR-Code:https://github.com/mchehab/zbar' ]; then echo $i; fi; done
../rotated/qr-code-183.png
../rotated/qr-code-342.png
../rotated/qr-code-72.png
../rotated/qr-code-73.png
QR encoding has pretty solid error correction which allows recovery of the data even if up to 30% of codewords are missing it seems, that's also how QR Code Art is possible.
QR encoding has pretty solid error correction which allows recovery of the data even if up to 30% of codewords are missing it seems, that's also how QR Code Art is possible.
I see. Yet, it sounds funny that there is a small range that are "blind spots" to the detection algorithm. Probably not worth fixing it, but for the 1D barcodes, it would be good if ZBar could do a lot better and read them with higher inclinations.
ZBar does not handle any inclination (exception: SQ code), it only processes space/bar pairs horizontally and vertically. In QR code, it detects the corner finders like 1D barcodes.
@mchehab Do you have some thoughts on how to approach this issue? I am working on rotation invariant barcode detection problem.
In the past, I handled edge detection using Canny and Hough, which looks like a good approach to start with. If one can localize barcodes, doing affine transformation should be enough as preprocessing to barcode detection. However, it puts a dependency on openCV.
Currently, ZBar is too sensible to image rotation, as can be shown with this small script:
Perhaps it should pass the image to an algorithm that would try to improve the image before running the decoders.