GithubHelp home page GithubHelp logo

zxing-cpp / zxing-cpp Goto Github PK

View Code? Open in Web Editor NEW
1.2K 1.2K 376.0 246.22 MB

C++ port of ZXing

License: Apache License 2.0

C++ 51.44% CMake 1.47% Batchfile 0.06% C 40.89% Python 0.33% HTML 0.51% QML 0.31% Kotlin 1.25% Swift 0.28% Objective-C 0.36% Objective-C++ 0.90% Ruby 0.05% Rust 1.26% C# 0.89%

zxing-cpp's Introduction

Build Status

ZXing-C++

ZXing-C++ ("zebra crossing") is an open-source, multi-format linear/matrix barcode image processing library implemented in C++.

It was originally ported from the Java ZXing Library but has been developed further and now includes many improvements in terms of runtime and detection performance. It can both read and write barcodes in a number of formats.

Sponsors

You can sponsor this library at GitHub Sponsors.

Named Sponsors:

Thanks a lot for your contribution!

Features

Supported Formats

Linear product Linear industrial Matrix
UPC-A Code 39 QR Code
UPC-E Code 93 Micro QR Code
EAN-8 Code 128 rMQR Code
EAN-13 Codabar Aztec
DataBar DataBar Expanded DataMatrix
DX Film Edge PDF417
ITF MaxiCode (partial)

[Note:]

  • DataBar used to be called RSS.
  • DataBar, DX Film Edge, MaxiCode, Micro QR Code and rMQR Code are not supported for writing.
  • Building with C++20 (see CMakeLists.txt) changes the behaviour of the library: it then supports multi-symbol and position independent detection for DataMatrix. This comes at a noticable performace cost. C++20 is enabled by default for the Android, iOS, Python and WASM wrappers.

Getting Started

To read barcodes:

  1. Load your image into memory (3rd-party library required).
  2. Call ReadBarcodes() from ReadBarcode.h, the simplest API to get a list of Barcode objects.

A very simple example looks like this:

#include "ZXing/ReadBarcode.h"
#include <iostream>

int main(int argc, char** argv)
{
    int width, height;
    unsigned char* data;
    // load your image data from somewhere. ImageFormat::Lum assumes grey scale image data.

    auto image = ZXing::ImageView(data, width, height, ZXing::ImageFormat::Lum);
    auto options = ZXing::ReaderOptions().setFormats(ZXing::BarcodeFormat::Any);
    auto barcodes = ZXing::ReadBarcodes(image, options);

    for (const auto& b : barcodes)
        std::cout << ZXing::ToString(b.format()) << ": " << b.text() << "\n";

    return 0;
}

To see the full capability of the API, have a look at ZXingReader.cpp.

[Note: At least C++17 is reqired on the client side to use the API.]

To write barcodes:

  1. Create a MultiFormatWriter instance with the format you want to generate. Set encoding and margins if needed.
  2. Call encode() with text content and the image size. This returns a BitMatrix which is a binary image of the barcode where true == visual black and false == visual white.
  3. Convert the bit matrix to your native image format. See also the ToMatrix<T>(BitMatrix&) helper function.

As an example, have a look at ZXingWriter.cpp.

Web Demos

[Note: those live demos are not necessarily fully up-to-date at all times.]

Build Instructions

These are the generic instructions to build the library on Windows/macOS/Linux. For details on how to build the individual wrappers, follow the links above.

  1. Make sure CMake version 3.15 or newer is installed.
  2. Make sure a C++17 compliant compiler is installed (minimum VS 2019 16.8 / gcc 7 / clang 5).
  3. See the cmake ZXING_... options to enable the testing code, python wrapper, etc.
git clone https://github.com/zxing-cpp/zxing-cpp.git --recursive --single-branch --depth 1
cmake -S zxing-cpp -B zxing-cpp.release -DCMAKE_BUILD_TYPE=Release
cmake --build zxing-cpp.release -j8 --config Release

[Note: binary packages are available for/as vcpkg, conan, mingw and a bunch of linux distributions.]

zxing-cpp's People

Contributors

axxel avatar benjohnde avatar corbers avatar dabrain34 avatar dainnilsson avatar duanqn avatar echterago avatar enzo-simone avatar gitlost avatar hartcw avatar huycn avatar isning avatar kientux avatar marcoffee avatar markusfisch avatar marxin avatar moodyhunter avatar musicinmybrain avatar okarmazin avatar pabs3 avatar parallaxe avatar sergio- avatar siiky avatar stumpylog avatar tcoyvwac avatar th1722 avatar trim avatar urishab avatar vkrause avatar zander avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

zxing-cpp's Issues

Unrecognized QR Code

This is an example of a QR code that is correctly decoded by zbarimg, but not with scan_png.
The command used was just scan_png "QR Code-test1.png"

qr code-test1

linker error when compiling for macOS

[100%] Linking CXX shared library libZXingCore.dylib
Undefined symbols for architecture x86_64:
  "ZXing::BitArray::getSubArray(int, int, ZXing::BitArray&) const", referenced from:
      ZXing::BitWrapperBinarizer::getBlackRow(int, ZXing::BitArray&) const in BitWrapperBinarizer.cpp.o
      ZXing::BitWrapperBinarizer::getBlackMatrix() const in BitWrapperBinarizer.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Seems to be related to d57cbe2#diff-5e24ace5ae61d1188c8939ca8d326e92R282

write barcodes

hello can you write a sample test of write barcode? I can not build success by your description

QR Text and Binary Encodings

There is something weird going on with text encodings. I've spent half a day trying to read the QR spec and the ECI spec to make sense of it and I'm a bit lost, so I'm not surprised it is difficult to implement correctly, but I know there's something off with TextDecoder::Append.

There's a comment in the code, copied verbatim from the old fork

The spec isn't clear on this mode; see
section 6.4.5: t does not say which encoding to assuming
upon decoding. I have seen ISO-8859-1 used as well as
Shift_JIS -- without anything like an ECI designator to
give a hint.

This bug is about this comment and the confusion in the QR spec around this issue.


If I use qrencode like this to encode a binary file:

curl "https://sampleswap.org//samples-ghost/DRUM%20LOOPS%20and%20BREAKS/161%20to%20180%20bpm/128\[kb\]161_amenvar3.aif.mp3" | qrencode -S -v 20 -8 -o /tmp/amen.png

one that includes embedded nulls all over the place:

$ curl "https://sampleswap.org//samples-ghost/DRUM%20LOOPS%20and%20BREAKS/161%20to%20180%20bpm/128\[kb\]161_amenvar3.aif.mp3" | xxd
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  8427  100  8427    0     0  42467      0 --:--:-- --:--:-- --:--:-- 42560
00000000: fff3 80c4 0000 0000 0000 0000 0058 696e  .............Xin
00000010: 6700 0000 0f00 0000 3c00 0020 eb00 040d  g.......<.. ....
00000020: 0d11 1115 1919 1d1d 2225 252a 2a2d 3131  ........"%%**-11
00000030: 3535 383c 3c40 4046 4b4b 4f4f 5356 565a  558<<@@FKKOOSVVZ
00000040: 5a5e 6868 7272 7579 797d 7d81 8484 8888  Z^hhrruyy}}.....
00000050: 8c90 9094 9498 9b9b 9f9f a3a7 a7ac acb0  ................
00000060: b5b5 b9b9 bdc1 c1c6 c6ca cdcd d1d1 d5d9  ................
00000070: d9dd dde2 e5e5 e9e9 edf1 f1f5 f5f9 ffff  ................
00000080: ff00 0000 394c 414d 4533 2e39 3972 0269  ....9LAME3.99r.i
00000090: 0000 0000 2e2e 0000 1428 2404 1f42 0000  .........($..B..
000000a0: 2800 0020 eb38 55ff ec00 0000 0000 0000  (.. .8U.........
...

And I upload the pieces to your demo, the reader succeeds:

Capture d’écran, le 2019-03-31 à 17 30 44

But scan_png garbles the header:

$ ./scan_png /tmp/amen-01.png | xxd
00000000: 5465 7874 3a20 2020 2020 c3bf c3b3 c280  Text:     ......
00000010: c384 0000 0000 0000 0000 0058 696e 6700  ...........Xing.
00000020: 0000 0f00 0000 3c00 0020 c3ab 0004 0d0d  ......<.. ......
00000030: 1111 1519 191d 1d22 2525 2a2a 2d31 3135  ......."%%**-115
00000040: 3538 3c3c 4040 464b 4b4f 4f53 5656 5a5a  58<<@@FKKOOSVVZZ
00000050: 5e68 6872 7275 7979 7d7d c281 c284 c284  ^hhrruyy}}......
00000060: c288 c288 c28c c290 c290 c294 c294 c298  ................
00000070: c29b c29b c29f c29f c2a3 c2a7 c2a7 c2ac  ................
00000080: c2ac c2b0 c2b5 c2b5 c2b9 c2b9 c2bd c381  ................
00000090: c381 c386 c386 c38a c38d c38d c391 c391  ................
000000a0: c395 c399 c399 c39d c39d c3a2 c3a5 c3a5  ................
000000b0: c3a9 c3a9 c3ad c3b1 c3b1 c3b5 c3b5 c3b9  ................

I can't tell if the QR Spec supports binary or just text encoded as binary. It's obvious to me that they were thinking mainly about textual data, but maybe they allowed others too? My experiment demonstrates that you can encode binary, and why shouldn't you be able to? QR includes length headers and their marketting even explicitly advertises a binary mode ("Numeric, Alphanumeric, Binary, Kanji").


Tracing shows that QRDecoder::DecodeByteSegment(), in the absence of an explicit ECI being set, tries to guess

https://github.com/nu-book/zxing-cpp/blob/549e2e8e4b492c9752adff296d4a44c6cd876693/core/src/qrcode/QRDecoder.cpp#L151-L165

and that will fall back to ISO8859-1:

https://github.com/nu-book/zxing-cpp/blob/549e2e8e4b492c9752adff296d4a44c6cd876693/core/src/TextDecoder.cpp#L503-L506

which explicitly flags the next step to just copy without interpretation:

https://github.com/nu-book/zxing-cpp/blob/549e2e8e4b492c9752adff296d4a44c6cd876693/core/src/TextDecoder.cpp#L227-L240

The rest of TextDecoder appears to store the output in directly as unicode (that's what wstrings are?). I guess ISO8859-1 must be a strict subset of unicode, so it doesn't need rewriting, and therefore can double, by accident as binary mode, so long as you later on know to interpret the wstring as bytes.


The QR Spec says

8.3.1: The default interpretation for QR Code is ECI 000020 representing the JIS8 and Shift JIS character sets.
8.4.4: In [8-bit Byte Mode], one 8 bit codeword directly represents the JIS8 character [...].
In ECIs other than the default ECI, it represents an 8-bit byte value directly.

I interpret this to mean inTextDecoder::Append(), the CharacterSet::Unknown case should be aliased to CharacterSet::Shift_JIS and in DecodeByteSegment(), only CharacterSet::Unknown or CharacterSet::Shift_JIS should call TextDecoder::Append(), but that in the case of "8-bit Byte mode" Shift-JIS should actually trigger JIS8. And otherwise, the bytes should be passed through undecoded. I don't know where other character sets are supposed to be allowed through. This all sounds insane, and I need help interpreting what is going on.

If that's the case, TextDecoder::Append()

That comment in DecodeByteSegment that I quoted is not correct: section 6.4.5 doesn't exist in the QR spec; section 8.3.4 and 8.4.4 is where "8-bit Byte mode" is described.


I suppose we could just, as a community, decide that binary mode is CharacterSet::Unknown. afaict that's what qrencode has already done.

If that's the case so, DecodeByteSegment() should be changed to not GuessEncoding() but just copy the data directly to the output.


There's this other annoying issue that QR Codes can come in mixed modes, with text in different character sets in the same code, but binary is not text.

The old fork's solution to handling multiple character sets was to coerce everything to UTF-8 as they went:

https://github.com/glassechidna/zxing-cpp/blob/e0e40ddec63f38405aca5c8c1ff60b85ec8b1f10/core/src/zxing/qrcode/decoder/DecodedBitStreamParser.cpp#L70-L74

(which ends badly when iconv chokes on non-textual data)

Yours is to coerce everything to unencoded unicode, calling it text.

But binary isn't text at all! It's something else. This type confusion is probably reason scan_png failed.


Related, several functions like

https://github.com/nu-book/zxing-cpp/blob/549e2e8e4b492c9752adff296d4a44c6cd876693/core/src/TextUtfEncoding.cpp#L268

conflate fixed-width UCS-2 (in uint16_t*) with variable-width UTF-16. For 99% of all test cases in practice, this is correct, for now, because no one ever writes unicode text that forces utf-16 to overflow into its variable width encoding. But it's not correct, and it's a lurking bug that will bite years down the road.


Thanks for reading. I know this was a long, windy, confusing bug report. Encoding issues are the worst thing.


Refs:

What about an unified header file?

IMHO it should be a nicer user experience to have a single ZXing.h file that needs to be included to use the whole library.
If you see the scan_image.cpp example there are 8 files that needs to be included to compile the code, a fairly amount.
Or maybe we can agree on having two files BarcodeReader.h and BarcodeGenerator.h

Thank you.

python wrapper does not accept multiple barcode formats

just like the title says, as far as I was able to see the python wrapper only accepts a single format for barcodes which is a major disadvantage.

I was able to change the pybind11 code to have multiple types accepted but cannot find out how to make this backwards compatible with the single type as well (with overloaded functions).

This is the code that works for multiple types, you can see the overloaded version I tried to add:

#include <pybind11/pybind11.h>
#include <pybind11/numpy.h>
#include <pybind11/stl.h>
#include <iostream>
#include <string>
#include "BarcodeFormat.h"
#include "DecodeHints.h"
#include "MultiFormatReader.h"
#include "GenericLuminanceSource.h"
#include "HybridBinarizer.h"
#include "Result.h"

using namespace ZXing;
namespace py = pybind11;

// Numpy array wrapper class for images (either BGR or GRAYSCALE)
using Image = py::array_t<uint8_t, py::array::c_style>;

Result decode(const Image& image, std::vector<BarcodeFormat> formats, bool fastMode, bool tryRotate, bool hybridBinarizer) {
	DecodeHints hints;
	hints.setShouldTryHarder(!fastMode);
	hints.setShouldTryRotate(tryRotate);
	if (formats.size()>0) {
		hints.setPossibleFormats(formats);
	}
	MultiFormatReader reader(hints);
	const auto height = image.shape(0);
	const auto width = image.shape(1);
	const auto bytes = image.data();
	std::shared_ptr<LuminanceSource> source;

	if (image.ndim() == 2) {
		// Grayscale image
		source = std::make_shared<GenericLuminanceSource>(width, height, bytes, width);
	} else {
		// BGR image
		const auto channels = image.shape(2);
		source = std::make_shared<GenericLuminanceSource>(width, height, bytes, width*channels, channels, 2, 1, 0);
	}

	if (hybridBinarizer) {
		return reader.read(HybridBinarizer(source));
	} else {
		return reader.read(GlobalHistogramBinarizer(source));
	}
}
/*
Result decode(const Image& image, BarcodeFormat format, bool fastMode, bool tryRotate, bool hybridBinarizer) {
	if (format != BarcodeFormat::FORMAT_COUNT) {
		return decode(image, {format}, fastMode, tryRotate, hybridBinarizer);
	}
	else {
		return decode(image, {}, fastMode, tryRotate, hybridBinarizer);
	}
}
*/
PYBIND11_MODULE(zxing, m) {
	m.doc() = "python bindings for zxing-cpp";
	py::enum_<BarcodeFormat>(m, "BarcodeFormat")
		.value("AZTEC", BarcodeFormat::AZTEC)
		.value("CODABAR", BarcodeFormat::CODABAR)
		.value("CODE_39", BarcodeFormat::CODE_39)
		.value("CODE_93", BarcodeFormat::CODE_93)
		.value("CODE_128", BarcodeFormat::CODE_128)
		.value("DATA_MATRIX", BarcodeFormat::DATA_MATRIX)
		.value("EAN_8", BarcodeFormat::EAN_8)
		.value("EAN_13", BarcodeFormat::EAN_13)
		.value("ITF", BarcodeFormat::ITF)
		.value("MAXICODE", BarcodeFormat::MAXICODE)
		.value("PDF_417", BarcodeFormat::PDF_417)
		.value("QR_CODE", BarcodeFormat::QR_CODE)
		.value("RSS_14", BarcodeFormat::RSS_14)
		.value("RSS_EXPANDED", BarcodeFormat::RSS_EXPANDED)
		.value("UPC_A", BarcodeFormat::UPC_A)
		.value("UPC_E", BarcodeFormat::UPC_E)
		.value("UPC_EAN_EXTENSION", BarcodeFormat::UPC_EAN_EXTENSION)
		.value("FORMAT_COUNT", BarcodeFormat::FORMAT_COUNT)
		.export_values();
	py::class_<ResultPoint>(m, "ResultPoint")
		.def_property_readonly("x", &ResultPoint::x)
		.def_property_readonly("y", &ResultPoint::y);
	py::class_<Result>(m, "Result")
		.def_property_readonly("valid", &Result::isValid)
		.def_property_readonly("text", &Result::text)
		.def_property_readonly("format", &Result::format)
		.def_property_readonly("points", &Result::resultPoints);
	m.def("decode", &decode, "Decode a barcode from a numpy BGR or grayscale image array",
		py::arg("image"),
		py::arg("format")=BarcodeFormat::FORMAT_COUNT,
		py::arg("fastMode")=false,
		py::arg("tryRoate")=true,
		py::arg("hybridBinarizer")=true
	);
}

No exported symbols in Windows

When builded with cmake on windows
cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_CXX_STANDARD=14 -DCMAKE_GENERATOR_PLATFORM=x64 ../
cmake --build . --config Debug
no .lib is generated, only .dll.

Distorted datamatrix codes fail to decode

@bommo1 came across a set of datamatrix samples that fail to decode because they are distorted. The larger the codes, the more likely will happen. Think: lens distortion, or not completely flat paper.

This issue is supposed to collect information about possible improvements.

One way to potentially solve the problem is by parsing the alignment patterns inside large codes (that is what they are there for anyway) and then sample each sub code with a regular grid. If the distortion relative to the module size is too big, that will also fail, though. For the provided samples below, this might have a chance.

Here are the samples:

1

4

medikationsplan1

Structured Append missing "N"

The "structured append" paging header has three parts: M, N and parity. M is the index of the current code, N is the number of codes in the set, and parity is the checksum to identify them all as belonging together. M and N are both 4 bits, but

https://github.com/nu-book/zxing-cpp/blob/e1d7de9cba1d912a3a13bd5e4c2e6deb80643d41/core/src/qrcode/QRDecoder.cpp#L340-L348

pulls both M and N into the same 8 bit variable. They should be separated and exposed as separate values. The DecoderResult misleadingly calls this 8-bit (M,N) tuple the "sequence number":

https://github.com/nu-book/zxing-cpp/blob/e1d7de9cba1d912a3a13bd5e4c2e6deb80643d41/core/src/qrcode/QRDecoder.cpp#L414

when in fact only the first four bits are that.

Can't recognize a dotted Datamatrix code

When I try to recognize one 285x450 matrix code image zxing lib can't find a code, but if I resize this image just a little to 259x408 the code can be found correctly

test_original

test_scaled

Some blackbox tests fail (on macos)

Working on the recent DMDetector bug, I was surprised to note that there are few unrelated blackbox tests that fail (see blow). Looking for a regression, I went back until I reached pretty much the first commit that allowed me to execute the tests on macos and all the tested versions fail for those files?!?

Trying to make sure there are no compiler dependent #ifdefs or undefined behaviors causing the problem, I came up with #33.

Still no idea what is going on with those files on my system. Question @huycn: Do all blackbox tests pass with your windows builds?

Here is a list of failing tests:

code128-2 @ 180°, total:  40, fast:  35 of  36
  FAILED: Not detected (fast): 11.png 12.png 28.png 30.png 37.png
ean13-1      @   0°, total:  34, fast:  29 of  30
  FAILED: Not detected (fast): 20.png 34.png 35.png 36.png 37.png
upca-1        @   0°, total:  21, slow:  17 of  18
  FAILED: Not detected (slow): 1.png 18.png 20.png
upca-1        @ 180°, total:  21, fast:  13 of  16
  FAILED: Not detected (fast): 1.png 10.png 12.png 18.png 19.png 20.png 3.png 4.png
     , slow:  17 of  18
  FAILED: Not detected (slow): 1.png 18.png 20.png

plus a bunch of qrcode tests.

Compile error on centos7

Build Step:

cd wrappers/winrt
cmake .
make

Build Errors:

1. leak c++11 options

  • ===========================================
    [ 1%] Building CXX object ZXingCore/CMakeFiles/ZXingCore.dir/src/BarcodeFormat.cpp.o
    In file included from /usr/include/c++/4.8.2/type_traits:35:0,
    from /root/ZXing/zxing-cpp-master/core/src/BarcodeFormat.cpp:21:
    /usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
    ===========================================
    solution:
    add following option to the CMakelist.txt
    ===========================================
    add_compile_options(-std=c++11)
    ===========================================

2. leak std::vector member function

  • ===========================================
    /root/ZXing/zxing-cpp-master/core/src/Result.cpp: In member function ‘void ZXing::Result::addResultPoints(const std::vectorZXing::ResultPoint&)’:
    /root/ZXing/zxing-cpp-master/core/src/Result.cpp:61:73: error: no matching function for call to ‘std::vectorZXing::ResultPoint::insert(std::vectorZXing::ResultPoint::const_iterator, std::vectorZXing::ResultPoint::const_iterator, std::vectorZXing::ResultPoint::const_iterator)’
    _resultPoints.insert(resultPoints().end(), points.begin(), points.end());
    ^
    /root/ZXing/zxing-cpp-master/core/src/Result.cpp:61:73: note: candidates are:
    In file included from /usr/include/c++/4.8.2/vector:69:0,
    from /root/ZXing/zxing-cpp-master/core/src/ByteArray.h:18,
    from /root/ZXing/zxing-cpp-master/core/src/Result.h:19,
    from /root/ZXing/zxing-cpp-master/core/src/Result.cpp:18:
    /usr/include/c++/4.8.2/bits/vector.tcc:107:5: note: std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::insert(std::vector<_Tp, _Alloc>::iterator, const value_type&) [with _Tp = ZXing::ResultPoint; _Alloc = std::allocatorZXing::ResultPoint; std::vector<_Tp, _Alloc>::iterator = __gnu_cxx::__normal_iterator<ZXing::ResultPoint*, std::vectorZXing::ResultPoint >; typename std::_Vector_base<_Tp, _Alloc>::pointer = ZXing::ResultPoint*; std::vector<_Tp, _Alloc>::value_type = ZXing::ResultPoint]
    vector<_Tp, _Alloc>::
    ^
    /usr/include/c++/4.8.2/bits/vector.tcc:107:5: note: candidate expects 2 arguments, 3 provided
    ===========================================
    Solution:
    replace with other member function:
    zxing-cpp-master/core/src/Result.cpp:61
    ===========================================
    void
    Result::addResultPoints(const std::vector& points)
    {
    for (size_t i = 0; i < points.size(); ++i)
    {
    _resultPoints.push_back(points[i]);
    }
    //_resultPoints.insert(resultPoints().end(), points.begin(), points.end());
    }
    ===========================================

3. Unable to visit the protected member function:

  • ===========================================
    [ 37%] Building CXX object ZXingCore/CMakeFiles/ZXingCore.dir/src/oned/ODUPCEANReader.cpp.o
    In file included from /root/ZXing/zxing-cpp-master/core/src/oned/ODUPCEANReader.h:19:0,
    from /root/ZXing/zxing-cpp-master/core/src/oned/ODUPCEANReader.cpp:18:
    /root/ZXing/zxing-cpp-master/core/src/oned/ODRowReader.h: In lambda function:
    /root/ZXing/zxing-cpp-master/core/src/oned/ODRowReader.h:184:15: error: ‘static float ZXing::OneD::RowReader::PatternMatchVariance(const int*, const int*, size_t, float)’ is protected
    static float PatternMatchVariance(const int counters, const int pattern, size_t length, float maxIndividualVariance);
    ^
    /root/ZXing/zxing-cpp-master/core/src/oned/ODUPCEANReader.cpp:58:100: error: within this context
    return RowReader::PatternMatchVariance(counters.data(), pattern, length, MAX_INDIVIDUAL_VARIANCE) < MAX_AVG_VARIANCE;
    ^
    make[2]: *** [ZXingCore/CMakeFiles/ZXingCore.dir/src/oned/ODUPCEANReader.cpp.o] Error 1
    make[1]: *** [ZXingCore/CMakeFiles/ZXingCore.dir/all] Error 2
    make: *** [all] Error 2
    ===========================================
    Solution:
    change protected to public(comment the key word "protected")
    /root/ZXing/zxing-cpp-master/core/src/oned/ODRowReader.h:183
    ===========================================
    //protected:
    static float PatternMatchVariance(const int counters, const int pattern, size_t length, float maxIndividualVariance);
    ===========================================

4. Demo depend on the windows api

  • ===========================================
    [ 98%] Building CXX object CMakeFiles/ZXingWinRT.dir/BarcodeReader.cpp.o
    /root/ZXing/zxing-cpp-master/wrappers/winrt/BarcodeReader.cpp:26:17: fatal error: wrl.h: No such file or directory
    #include <wrl.h>
    ^
    compilation terminated.
    ===========================================

Unrecognized QR code #2

This is an example of a QR code that the Camera app in iOS will correctly decode, but neither zbarimg nor scan_png are detecting.

qr code-test2

Can't encode 0xb7 byte

When I try to encode single byte 0xb7, after decoding it becomes 0xff77. Minimal example to reproduce:

#include <iostream>
#include <cassert>
#include <fstream>
#include <ZXing/qrcode/QREncoder.h>
#include <ZXing/qrcode/QRDecoder.h>
#include <ZXing/qrcode/QRErrorCorrectionLevel.h>
#include <ZXing/CharacterSet.h>
#include <ZXing/qrcode/QREncodeResult.h>
#include <ZXing/DecoderResult.h>
#include <ZXing/ByteArray.h>
#include <ZXing/BitMatrix.h>

using namespace ZXing;
using namespace ZXing::QRCode;

void print_byte_data(const std::wstring & wdata){
  for(wchar_t el : wdata){
    printf("%02x:", el);
  }
}

int main(int argc, char ** argv){
  const char * data = "b7:";
  unsigned val;
  const char * cur_ptr = data;
  std::wstring wdata;
  while(true){
    int read = sscanf(cur_ptr, "%02x:", &val);
    if(read > 0){
	wdata.push_back(wchar_t(val));
	cur_ptr += 3;
    } else {
	printf("\n");
	break;
    }
  }

  printf("Encoding: ");
  print_byte_data(wdata);
  printf("\n");

  auto qrCode = Encoder::Encode(wdata, ErrorCorrectionLevel::Low, CharacterSet::Unknown, 0, 1);
  auto decoded = Decoder::Decode(BitMatrix(qrCode.matrix, 1), "");

  printf("Decoded: ");
  print_byte_data(decoded.text());
  printf("\n");

  return 0;
}

Expected output:

Encoding: b7:
Decoded: b7:

Real output:

Encoding: b7:
Decoded: ff77:

Multithreading / Thread Safety / Usage scenarios

My recent thread-safety regression (see #91) raised a question: what is the use case for supporting multi-threading / thread-safety?

The current state of the code promises thread-safety on a 'decoder object level' (if I'm not mistaken, that is). I.e. you can instantiate e.g. a MultiFormatReader and then share that with several threads who work on different images concurrently. What they then share is basically the DecoderHints that are stored inside the decoder objects.

My recent regression fix would not be required if the different threads would simply be required to instantiate their own MultiFormatReader. Is there an advantage of sharing that reader object across threads?

What is the use-case for having multiple threads work on separate images in the first place? I see how that could speed up the blackbox-testrunner but in a typical (mobile) app: where do those multiple images come from? Would it not be significantly better if the MultiFormatReader used multi-threading internally to decode one image at a time faster?

There are several parallelism opportunities:

  1. run multiple decoders in parallel on the same image data
  2. run the 1D decoders in parallel on different scan-lines

1D readers should not test for upside-down codes if tryRotate is false

I'm currently falling down a rabbit hole after I fired up a profiler for fun ;). Apart from other changes that I'm about to push I'd like to propose a change in the default behavior of the 1D readers. It turns out that the time spent in false-positives-tests is by far dominated by the 1D decoders. If you are only interested in upright codes (by setting tryRotate to false), you should not have to pay for an implicit upside-down check, which is currently the case.

People who formerly relied on that behavior would have to specify tryRotate = true in the future. Any objections?

Request for CLI

It would be great to have a command line interface included in the project.
I have been looking high and low for a command line tool that is actually able to reliably detect various barcodes in images.

E.g. zbarimg 0.10 CLI is not able to detect all QR Codes that e.g. the iPhone camera app recognises, and the CLI provided with https://github.com/glassechidna/zxing-cpp is not able to detect the QR codes zbarimg recognizes... ☹️

Some blackbox tests fail when enable gcc optimization

When build with -DCMAKE_BUILD_TYPE=Release with GCC, where optimization -O3 are used, code run much faster (5x), however some blackbox tests fail. I narrowed it down to EAN13Reader that no longer works as expected. There is still issue at -O1 level, only -O0 will work.

Make this the "official" zxing-cpp?

There are currently hundreds of forks of zxing-cpp out there with two main "base"-forks as far as I can tell: this one and https://github.com/glassechidna/zxing-cpp

For concentrating efforts and for packaging in distributions (linux, chocolately, home-brew, ports, ...) it would be great to have one "main" fork. This one seems to be a) the most active in recent times, b) has unit tests for all codes and c) has a version number/release since yesterday. So if you agree it would be great to focus on this one.

Any thoughts or objections?

We could even "move" it to zxing/zxing-cpp or zxing-cpp/zxing I guess

CMake restructuring

I'd like to propose a change in the CMake setup. Instead of having lots of individual cmake projects in each subdirectory that all build the whole library themselfs, we should have one top-level project with a bunch of options for building with tests/examples/wrappers/etc. This should result in less confusion on what to build if you just want to have the lib with an example binary and we could also disable some wrappers based on the platform (see #85).

It would also reduce the amount of build directories to deal with during development just to make sure everything still compiles.

@huycn are you somehow dependent on the current 'multi-project' setup?

Interleaved 2 of 5 with bearer bar not recognised

Recognition of interleaved 2 of 5 codes with a bearer bar fails when the second END_PATTERN_REVERSED is used (this will be the case when the barcode's wide to narrow ratio is 3).
After some debugging I found that when searching the end pattern the calculation of the narrow line width is wrong in this case because the length of the pattern is 5 in this case and not 4.
I managed to fix the issue by replacing line 159 in ODITFReader.cpp:

int narrowLineWidth = (end - begin) / 4;

by the following:

int patternLength = 0;
for( int i = 0; i < pattern.size(); ++i )
{
	patternLength += pattern[ i ];
}
int narrowLineWidth = (end - begin) / patternLength;

Shared library has no soversion

It's only installed as a single .so instead of so.$soversion. A soversion is important at least for coinstallability (and important to get this library packaged in distributions).

Issue with MSVC iterator guard in DEBUG

Hello,
this is gonna be a debatable one as it deals with Microsoft specific environment, but let me expose.

Method ZXing::BitArray::isRange is defined as
bool isRange(int start, int end, bool value) const { return std::all_of(&_bits[start], &_bits[end], [value](uint8_t v) { return v == static_cast<int>(value); }); }
but accessing _bits[end], i.e. past the end, triggers an assertion just during debugging though is perfectly legitimate to get its address since &_bits[end] == &_bits[0] + end.

A solution could be
return std::all_of(std::begin(bits) + start, std::begin(bits) + end, [value](uint8_t v) { return v == static_cast<int>(value); });

Thank you.

#define ZXING_VERSION_MAJOR...

#define ZXING_VERSION_MAJOR 1
#define ZXING_VERSION_MINOR 0
#define ZXING_VERSION_PATCH 3

This would be extremely helpful. For more than obvious reasons I think. I can do it. I just want to make sure everyone is on board.

PS: Maybe in the "ZXConfig.h" file?

C2039

Class "Gdiplus: : Bitmap" has no members "ConvertFormat"

vactor subscript out of range?

	std::wstring c = L"ABC" ;
	ZXing::BitMatrix mar(100);
	ZXing::QRCode::Writer writerQR;
	writerQR.setEncoding(ZXing::CharacterSet::UTF8);
	writerQR.encode( c, 100, 100, mar);

eeeeeeeeeeee

eor

How can you make a qr code?

Restructure 1D algorithms for potentially substantial performance gains

After having spent some time with a profiler on the ODReaders and having heard that the performance of the library on an (unknown) phone platform is only around 1 fps (even after the recent improvements) - I'm wondering whether there was interest in some structural changes of the ODReader to make it (hopefully considerably) faster?

@huycn: Can you give me some numbers from your real-world mobile app (preferably from the current HEAD code)?

  1. image input size (maybe a typical sample image?)
  2. fps / decoding time for one frame
  3. list of enabled readers

Looking at where the time is spent overall in a 'check everything' MultiFormatReader setup, one realizes that the majority of time is spent on the 1D readers. And in them a considerable amount is spent on

  1. going through the bits and counting how many successive bits are of the same value
  2. going through the bits again to see if there is enough 'quite zone' in front of the current pattern

Point 2 is already bad but worse is that both are repeated for each and every ODReader on the same set of bits. I recently made that part faster but even better would obviously be to perform it once instead of up to 11 times.

This would require to rewrite the detection part. Apart from the question of whether I will actually find the time to do that, I wanted to make sure the resulting deviation from upstream is not something that would kill your interest in merging it right from the start.

As far as I can tell, the upstream project is pretty much dead and the occasional fix worth porting over is mostly in the nasty decoding side of the puzzle, not the detection. So nothing to worry about.

Build instructions missing

Could you please provide some build instructions for building with the Android NDK? That would be greatly appreciated!

Using ConvertUPCEtoUPCA, compile error

Hello,
using MSVC I'm trying to use the function
ZXing::OneD::UPCEANCommon::ConvertUPCEtoUPCA

defined in
ZXing/oned/ODUPCEANCommon.h

so in my project I included
#include <ZXing/oned/ODUPCEANCommon.h>

but the latter includes
#include "ODUPCEANReader.h"

which in turn includes
#include "oned/ODRowReader.h"

which fails because files "ODUPCEANReader.h" and "ODRowReader.h" are in the same directory.

Thank you.

DMDetector.traceGaps() endless loop

@axxel Thank you for your improvements to the detection of datamatrix codes!

I've found an example where the detector loops forever in the traceGaps() method.
Probably due to rounding in traceStep() p doesn't change after an iteration.

frame_00034

.wasm usage with Webpack

Hello there,

Thank you for this port of ZXing 😉
I am trying to use the wasm target with Webpack but cannot get it to work.

I do not know much about wasm and emscripten but I am also using opencv.js that uses also emscripten and their emscripten built file only require one JS file as the wasm binary is embedded into that .js file. With this output, it works like a charm when used with Webpack.

You can see their output here : opencv.js.txt with var wasmBinaryFile.

Also, I think a less generic export than Module would be better. What about using ZXing instead ?

Do you have any idea how to get a similar build as OpenCV (only one JS file with embedded wasm binary) using emscripten ?

Thanks !

[Q] Custom barcode zebra format

Hello
I wonder if it's possible to create a custom barcode that will be unique to me?
can i create another format of my own using predefined symbols and spaces and line widths ?

let say i want to set that
e.g:
| || | ||| | = 1
|| || | | ||| = 2

and to be able to use zxing to read this custom barcode?

Thanks a lot

Inconsistent naming of the "tryHarder" feature

I noticed that there seems to be a divergent use of names for the DecodeHints::setShouldTryHarder() functionality:
@huycn called this flag 'fast' / 'fastMode' in the scan_image example
@timrae followed that example in his python wrapper
@dabrain34 used the term 'TRY_FASTER' in his gstreamer plugin
@swex sticked to 'tryHarder' in his Qt wrapper

I would like to suggest to come to an agreement about how we'd like to call that flag and name it consistently (before it is "too late"). As I see it, the basic difference between the terms tryHarder and fastMode is that they imply a different default value for the underlying functionality. I believe the upstream term tryHarder (next to the similar tryRotate) is the more appropriate one, as the word implies both (better results but also longer execution time) where as a simple 'fastMode' sounds as if you would always want that (fast == good, right?).

Ideally, we would not need either of those flags if the code were simply fast enough with both enabled.

However we end up calling it, I'd like to remove the word "should" from the DecodeHints methods. I believe it is unnecessarily verbose and also misleading: as if the computer would have a say in whether or not he will actually do what he is asked to :).

Anyone who has an opinion about the matter, please let me know.

Nuget package version is out of date (1.0.3 vs 1.0.5)

The current release is of the project according to CMakeLists.txt is 1.0.5, but the ZXingWinRT.nuspec still shows as version 1.0.3

The impact here is that when generating a nuget package the wrong version number code will be used.

Depending on when and how this is being published to nuget.org, it may also result in failing to deploy the latest version of the library unless there's a manual step taken to update it before publishing.

EAN-13 not recognized on Android

Hi

I have prepared an example in which app detects QR and EAN-13 code. It works fine on Linux, but on Android I can't recognize EAN-13. On my desktop Linux both works very fast, QR Code works also fast on my Android phone, but EAN-13 works only on Linux.
I have compiled static libraries for linux (Debian 64Bit) and android (armeabi_v7a ) in my example.
I'm using Qt 5.12.3 and @swex Qt port
I'm aware of the @ftylitak Qt port but it is unfortunatelly crashing when I use Felgo framework, which I have reported.
I'm testing on Android 7.0 with NDK r20
I'm cross compiling for android with command:
cmake . -DCMAKE_SYSTEM_NAME=Android -DCMAKE_TOOLCHAIN_FILE=/opt/Android/Ndk/android-ndk-r20/build/cmake/android.toolchain.cmake
If I specify
-DANDROID_PLATFORM=android-28
I'm getting this error during app building:
zxing-cpp/core/src/pdf417/PDFReader.cpp:42: error: undefined reference to 'abs'
So library is build for API 16.
Example is here:
https://github.com/frankipl/zxing_test_ean_13

Can You help, please

Best Regards
Marek

VS Build

Hi,

I've been trying to build various zxing-cpp forks on Windows and it's been rather difficult. My use case doesn't require encoding, so your current decoder setup should be great.

Do you have any tips on building this in VS?

Thank you for starting this new fork, I've used the library from Java and it has been the best of the bunch.

Best,
Boris

Find out DecodeStatus (error codes) when decoding QrCodes

Is there a way to expose decoding info to find out what went wrong when a qrcode fails to be decoded?

This can be helpful to be able to tell if the image had a QrCode that failed to read or if the image did not have any QrCode at all.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.