By Alain Nyeck
Data Matrix is a compact, 2-D symbology capable of holding relatively large amounts of data compared to earlier-generation barcodes. The main benefits of Data Matrix compared to the earlier linear symbologies include higher information density, scalability, omnidirectionality, and stronger error-correction capability. Data Matrix is becoming the 2-D barcode of choice, especially where space is at a premium, such as on semiconductor wafers and circuit boards.
The popularity of Data Matrix symbology and its convenience for barcode applications has led to the development of many software readers, and choosing the right software package for the developer, machine-vision integrator, or end user is a challenging task. For example, direct-part-mark-identification machine-vision applications require fast and reliable reading of Data Matrix codes marked directly on the toughest surfaces, such as metal, glass, ceramic, and plastic. These codes can become distorted due to the manufacturing process, and many are poorly marked with missing or inconsistent features. This can create significant challenges for machine-vision applications.
Data Matrix Characteristics
Data Matrix encodes data in a square or rectangular 2-D array. A fixed pattern on the perimeter of the data array, including an L-shaped solid border on one side and alternating pattern on the other side, is always present. This pattern allows locating the matrix but also determines its dimensions (counting the number of cells horizontally and vertically; see Fig. 1).
The L-shaped pattern that makes up the left and bottom sides of the perimeter is used to locate the position and orientation of the matrix inside the image. Even when the matrix is rotated, scaled, or linearly warped, the Data Matrix reader can locate it. The alternating light and dark cells on the right and top sides of the perimeter allow the software reader to measure the size of the matrix in both dimensions. The data are encoded in all the remaining cells inside the perimeter, and the quiet zone is the clear area of at least one cell width that surrounds the symbol on all four sides.
The original specification of the Data Matrix symbology used convolution error correction with five different levels: ECC 000, ECC 050, ECC 080, ECC 100, and ECC 140. The enhanced form of the symbology, also known as ECC 200, uses the Reed-Solomon error-correction algorithm, allowing recognition of barcodes that are up to 60% damaged. It is the only version recommended for new applications.
ECC 200 symbols have an even number of rows and columns. There are 24 square symbols and six rectangular symbols available in ECC 200. The ECC 200 Data Matrix format can encode up to 3116 numeric digits, 2335 alphanumeric characters, or 1556 bytes of binary data in a symbol that is 144 modules square (see Table 1).
Evaluation Criteria
Given the fact that machine-vision applications require a certain level of robustness and speed, a thorough evaluation of available off-the-shelf reader software based on well-chosen criteria can significantly increase the efficiency and reliability of your application. A general evaluation of reader software should rely on two main criteria: performance and ease of use.
Performance-The reader software’s performance has a direct impact on the efficiency of your application. Reader software must fulfill all the requirements of 2-D symbol applications, including achieving a high success rate while providing a fast execution time. Performance can be evaluated using two dimensions: robustness and speed.
Robustness-The robustness of reader software can be defined as the ability to consistently localize and read codes in an image under a wide range of image distortions and symbol quality. Robustness is the major criteria to be considered when evaluating reader software, and, obviously, robustness is not easily quantifiable.
The basic quality of the Data Matrix symbol can be determined through verification standards, including those provided by AIM Global-The Association for Automatic Identification and Mobility (Warrendale, PA, USA; www.aimglobal.org) and the International Aerospace Quality Group (IAQG; www.iaqg.sae.org/iaqg). The AIM standard measures the symbol contrast, print growth, axial nonuniformity, and unused error correction, allowing grading a symbol by degree of acceptability-from A that indicates excellent to F that specifies a failure. The IAQG standard is well suited to dot-peened codes and provides a quantitative measure for dot size, dot position, and dot ovality.
Many aspects related to image acquisition and the content of the observed area can greatly affect the success of the software. One measure of robustness is how well the software tolerates geometric transformations, such as rotation, scaling, and warping. Rotation-invariant software can read a barcode at any angle in an image without being affected by the angle change. This also applies to the scale-invariant property of reader software, in which it can read a Data Matrix symbol up to a cell size of one or two pixels wide.
In 2-D barcode applications, several sources of image contrast are encountered. For instance, poor lighting often results in a changing (or even nonlinear) background. Reader software must be able to handle the reflection of light on metallic or glass surfaces that creates artifacts in the image; noisy, saturated, poorly contrasted, or blurred images; and other types of degradations to the appearance of the code such as badly formed codes with misaligned cells, inconsistent symbols, missing or extra parts, or marking quality (see Fig. 2).
Speed-The goal is not to determine how long it takes to read a code, but how the image and code distortions may affect the execution time. The code-reading process can be divided into two phases: the localization of the symbol and the decoding.
The localization stage involves segmentation and feature extraction algorithms, the execution time of which depends upon the image content. As in practice the image content changes and various types of image degradation (for example, noise and background variations) occur, the execution time during the localization stage varies and can be nondeterministic. The decoding phase involves recognizing the symbol size, discriminating between light and dark cells, and extracting data to be decoded accordingly.
Generally, reader software performs well on grade-A type symbols while decreasing the read speed on degraded or poorly contrasted symbols in the same field of view. The speed during the decoding stage may be affected by the previous symbol-location accuracy, the Data Matrix symbol size, and the ability of the reader to distinguish light and dark cells on various image-contrast and background conditions. Other constraints that should be considered when evaluating speed are the number of codes to read in a single execution.
Table 2 illustrates execution times obtained on sample images presenting various robustness constraints. In this case, the reader used is the DALSA Barcode Tool, and the system used for the benchmark is a P4 3.2 GHz PC with 1 Gbyte of memory (DDR 333) and running the Windows XP operating system.
Good reader software might be a program that provides the best average speed over images with errors. If the software is not fast enough to keep pace with the input data rate, it must at least be flexible enough to provide controls that allow robustness to be balanced with speed, such as setting the Data Matrix size, selecting the segmentation algorithm, and timing out the execution.
Ease of use
The success of a program depends on its ability to be used by people with various levels of skill and experience. An easy-to-use program must provide completely automated mechanisms. In practice, this means that all the parameters internally used to adjust the algorithm’s behavior must be computed automatically from the input images, and only a reduced set of intuitive controls should be exposed to the user.
Ease of use also requires a simple and flexible programming architecture to accelerate the system-integration process. For less-challenging applications, the simplicity of a point-and-click high-level programming interface may minimize the learning curve and the development time, specifically for machine-vision application developers with limited experience.
On the other hand, reader software may provide a highly configurable and powerful API to help advanced programmers address a range of complex applications. The programming language itself and/or the software technology supported by the software are not critical issues as long as the tool provides a simple and intuitive architecture, good documentation, and a complete series of code samples.
Alain Nyeck is software developer at DALSA, Waterloo, ON, Canada; www.dalsa.com.
Custom system reads multiple barcodes
Gunther International (Norwich, CT, USA; www.guntherintl.com) provides intelligent, efficient, and modular equipment for document mailing, folding, and finishing. To develop a more cost-effective and user-friendly system that could read all barcode symbologies. Joseph Truax, company R&D engineer, evaluated the use of smart sensors but rejected them because of their inability to read anything other than 2-D barcodes.
Traux develop new equipment with technical assistance from machine-vision distributor and integrator 1stVision (Andover, MA, USA; www.1stvision.com). The primary reader was outfitted with a 1stVision MC0-CC-P60 camera equipped with a 1/3-in. Sony progressive-scan sensor, which images the barcode on each document before it starts down the path to being folded, printed, or otherwise processed. The barcode data are transferred to a DALSA PC2-Vision frame grabber, which converts the image into digital format and transmits it to the host PC running the vision application. The operator interface was developed in-house using Visual Basic and implemented in DALSA’s Sherlock Windows-based software environment, which includes MVTools.
By decoding each barcode, the system determines how to assemble each package-that is, which bills, statements, and marketing inserts to fold and insert into each envelope, or how to bind a specific group of documents. A second reader at the end of the process verifies the proper assembly of each package. Seven of Gunther’s machines have been upgraded with this vision system, and Traux is now developing a new linescan application for more-extensive back-end verification that each process was performed properly.
