I am trying to develop an application that will use tickets given the user the ability to validate them. I am wondering why I should choose Aztec barcode as many many companies have already chosen that instead of QR-Codes. What are the pros of the Aztec barcodes?
I good comparison I have found so far is:
http://www.tec-it.com/en/support/knowbase/barcode-overview/2d-barcodes/Default.aspx
and here: http://en.wikipedia.org/wiki/Aztec_Code
on Usage section you can see that is used quite often.
Although Aztec Codes are more compact and tunable, there is poor support for them among open, non-proprietary software. I would still use QR Codes for now, which have very mature software support on a wide variety of platforms.
If space is at a premium for you, and you do not care for users to be able to read or generate your codes with their own software or on a wide variety of devices, then Aztec would be a better choice. Aztec codes do not require a surrounding margin, allow for very finely tunable error correction level, and have a tighter encoding optimized for a wider range of message texts.
For example, the Aztec codec has a mode specialized for encoding lowercase letters, so it could encode most of this question answer with only 5 bits per character. The QR codec is only optimized for uppercase URLs, and must store lowercase letters as full 8-bit binary data. A QR code containing this text would have to encode about 160% as much data as an Aztec code -- and then it needs a margin space too.
QR codes require more space than Aztec codes but have freely available software supporting them.
Aztec codes can store more information, but there is poor free support for them. They can be harder to read and generate efficiently, right now.
On an Android phone, Google's "Barcode Scanner" application will scan an Aztec code after a longer delay than a QR code, and the user has to manually enable Aztec code scanning in the application preferences.
Similarly the free barcode generator package "zint" will produce Aztec codes, but has a handful of bugs, and does not make full use of the codec to optimize their size as small as possible. Its generation of QR codes, on the other hand, is bulletproof.
I share the frustration with the comparative incompleteness of FLOSS support for encoding and decoding Aztec Code, expressed in #fuzzyTew's answer.
There is much more open-source code for encoding and decoding QR, compared to Aztec, and it is more feature-complete and thoroughly tested.
That's a shame, because Aztec Code is in several ways superior to QR. As described in #fuzzyTew's answer…
Aztec doesn't require a “quiet zone” of white space around the symbol, while QR does.
Aztec offers continuously-tunable error correction levels, whereas QR code offers only a few discrete levels.
Aztec offers substantially higher density than QR, for typical applications consisting mostly-to-entirely of standard ASCII text.
Compared to Aztec, QR is particularly inefficient for encoding lowercase Latin letters (8 bits/char) compared to Aztec (5 bits/char).
The largest QR size, 177×177 blocks, can store 2953 bytes in binary mode with Low error correction (~7%), while the largest Aztec size, 151×151 blocks, can store 2318 bytes in binary mode with equivalent 7% error correction. At that size, Aztec requires ~9.83 blocks/byte, while QR requires ~10.61.
Much of the open-source support for Aztec is based on ZXing. That includes the Android Barcode Scanner app, and many online encoders and decoders.
Until recently, ZXing's Aztec Code implementation did not correctly support the encoding or decoding of non-Latin1 characters. (QR, Aztec, PDF417, and Data Matrix all use ECI to support other character encodings.)
Recently I've started doing something about it:
I added support for correctly decoding non-Latin1 characters from Aztec in ZXing.
I added support for correctly encoding non-Latin1 character sets to Aztec in ZXing.
I also added support for encoding non-Latin1 character sets in the Python aztec_code_generator module.
The point of all this is: There's not actually a ton of work to be done to get open-source Aztec encoders/detectors/decoders of a high quality.
Related
We are using R/exams to create tests in Canvas and TestVision.
We have other forms and other software to perform written exams.
I know R/exams has a great NOPS feature and was wondering:
What software is used to autograde the NOPS forms?
Can that software also evaluate string questions?
Now it looks that the NOPS form doesn't make it easy for software to read parts. Ideally the software would be adapted so adapted NOPS forms (changes in blue) could read more easily Student Name, and string questions:
NOPS format
The NOPS forms have not been designed by us but they follow the format that our university has been using. We simply mimicked their format because we initially just generated the PDF files ourselves but used the commercial scanning software of our university.
Scanning
However, over the years we have written our own scanner implementation in R in exams::nops_scan(). The basic approach is to convert PDF pages to PNG images, read these into R, convert them to black and white pixel matrices, find the scanner markings in the corners, and then extract just the boxes relative to these markings. The boxes either contain printed digits in a fixed font for which a simple decision tree yields a reliable classification - or the boxes are empty/filled vs. checked which can also be classified reasonably reliably. The result is stored in a simple text format that was again not developed by us but to be fully compatible with the commercial system that our university used.
Grading
Based on the scan results the function exams::nops_eval() computes points and grades. Various evaluation strategies can be plugged in and starting from version 2.4-0 the reports generated by the function can be customized.
Extension to OCR
At the moment no OCR (optical character recognition) is used, except for the simple task of recognizing printed numbers in a fixed font. But no hand-written characters or digits are ever evaluated automatically. I had played around with this a little bit using tesseract but the results were not reliable enough for our purposes.
The string questions that are currently supported are intended for open-ended questions. Hence students get a reasonable amount of space to write something down. The teacher can then grade the answer sheet manually, again by ticking boxes only, which can be read rather reliably. The scanned images of the full sheet are included in the report for the students so that they can also see any hand-written feedback/corrections included in the answer form.
Tutorial
A hands-on guide to using the NOPS approach is available at: http://www.R-exams.org/tutorials/exams2nops/
Misc
Unfortunately, the system is not implemented in a very modular fashion. The reasons for this were two-fold: (1) We followed very closely the given format our university had been using. (2) The bulk of the implementation was written under a lot of time pressure (see the anecdote below). So while the features you propose would be nice to have, they are unlikely to fit well into the current setup. If you would want to have a stab at this, I would recommend to write a modular new implementation, just using the bits and pieces from the existing code that are useful enough.
Anecdote: Scanning of about 400-500 exam sheets had failed on the university system due to a mistake of the copy shop that had printed the sheets. It was mid-July, everybody was on vacation already including myself. So I sat on my parents porch for two days to write the scanner tool and evaluate the exams that the students were waiting for.
My question is for QR Code support on the ZOS platform. We have legacy systems that produce many printed documents and mailings. I have been tasked with the challenge of developing a called routine that can receive a 200 byte string of variable data and return the encoded data for a QR Code. I’ve walk through a series of mathematical calculation required to encode the data in the algorithm for printing with a barcode font.
I wondered if someone has already tackled this task on the mainframe.
I am looking for short cuts on the mathematical encoding portion in COBOL. I have seen several applications out there that were designed for other platforms and other languages. Has anyone experimented with creating QR Codes on the Mainframe or know of any dynamic processes that can handle the calculation portion of the encoding?
Recently I was seeing OpenCL EP support on some development boards like odroid XU. One thing I know is that OpenCL EP is for ARM processors, but in what features will it vary from the main desktop based OpenCL.
The main differences are enumerated below (as of OpenCL 1.2):
64-bit integer support is optional.
Support for 3D images is optional.
Support for 2D image array writes is optional. If the cles_khr_2d_image_array_writes
extension is supported by the embedded profile, writes to 2D image arrays are supported.
There are some limitations on the available channel data types for images and image arrays (in particular, images with channel data types of CL_FLOAT and CL_HALF_FLOAT only support CL_FILTER_NEAREST sampler filter modes)
There are limitations on the sampler addressing modes available to images and image arrays.
There are some floating-point rounding changes that you may need to take into account.
Floating-point addition, subtraction, and multiplication will always be correctly rounded, other operations such as division and square roots have varying accuracies. There are tons of other floating-point things to watch out for as well.
Conversions between integer data types and floating point integers are limited in precision (but there are exceptions).
In short, the main differences here are in floating-point accuracy. In other words, the embedded profile need not adhere to the IEEE 754 floating-point specification, which may be a problem if you are doing lots of numerical calculations which rely on it. Quoted from the specification:
This relaxation of the requirement to adhere to IEEE 754 requirements
for basic floating- point operations, though extremely undesirable, is
to provide flexibility for embedded devices that have lot stricter
requirements on hardware area budgets.
There is also something that is not mentioned in section 10 but is worth noting: while desktop profiles must have a compiler available to compile OpenCL kernels, embedded profiles need not provide one. This can be seen through the clGetDeviceInfo documentation, which states:
CL_DEVICE_COMPILER_AVAILABLE: Return type: cl_bool
Is CL_FALSE if the implementation does not have a compiler available
to compile the program source. Is CL_TRUE if the compiler is available.
This can be CL_FALSE for the embededed (sic) platform profile only.
For a complete and detailed list of the OpenCL Embedded Profile specification, fire up your PDF reader, download the OpenCL spec (whichever version you are developing for), and find the relevant section.
The section 10 in the standard answers your question. This section is entirely dedicated to the OCL embedded profile, ans starts by enumerating the restriction that this profile implies.
The QR code specification requires an optimal choice of mask to avoid patterns that are difficult to scan. If the rules for this choice are ignored and one of the mask patterns is chosen arbitrarily, but the scanner is not confused by the pattern while scanning it, will there be any decoding problems?
Yes, sometimes. Due ISO/IEC 18004:2000 (8.8), masking is used for:
balancing dark and light modules,
avoiding Position Detection pattern.
The first one will affect on version detection, which is made provisionaly for versions of QR code less than 7.
The second one will affect on position patterns detection.
Both these steps should be done before reading Format Information and applying mask to QR code while decoding.
No. The mask that is used is recorded in the QR code itself, in the area around the finder patterns. As long as that is read correctly, the mask will be correctly removed before decoding. It doesn't matter whether it's actually the optimal pattern or not. Any mask may be used in theory.
I wanted to know whether
A file encryption algorithm can be designed in such a way that it can perform the activities of a file compression as well (any live example?).
Also can I integrate it to a Mobile SMS Service, I mean for text messages?
Also I wanted to know about binary files...if a plain text file is encoded in binary does its size reduces? Also is it better to encode a plain text file to a binary one rather than encoding it to any other format (in case if anyone wants it to encode for any purpose)
In fact all decent encryption programs (take PGP for example) compress data before encryption. They use something mainstream like ZIP for compression. The reason is once data is encrypted it looks like random noise and becomes incompressible, so it can only be compressed before encryption. You likely can't do that for SMS - you have to obey the specifications for the SMS so you'd better check those specifications.
Compression removes redundant information. Redundant information makes breaking an encryption easier. So yes, encryption and compression are compatible. I don't know if there is an algorithm designed to do both things though.
Yes, a binary file will usually be smaller than a plain text file. For instance, the number 34 written out in text takes 2 bytes (at least) whereas in those same 2 bytes you could write a number as large as 65000.
What makes an encoding "better" than another is the purpose to which it is put. If you are optimizing for size, binary is probably better. If you are optimizing for readability or graceful failure, text might be better.
First question: No reason why it shouldn't be possible. Since you can still encrypt compressed data and vise versa, you can test the benefits by trying. I don't know if it can be used for text messaging, but you'd have to explain what you're trying to do if anyone wants to give a reasonable and fitting answer.
Second question: plain text is still binary, it's just readable and encoded in a certain character set. Main difference is that plain text usually conforms to a certain encoding, say UTF-8 or ISO-8859-1.
You can still compress plain text, which makes it "binary" in the traditional sense that you only see weird bytes. :-)