Why Dot Symbols do not pass ISO/IEC 15415 and what can be done about it

The process of grading a 2D matrix symbol according to ISO/IEC 15415 begins with the process of decoding it according to the symbology specification (reference decode algorithm). Actually, it begins by blurring and thresholding the image, and then running the reference decode algorithm, but essentially, it is dependent upon the reference decode algorithm for creating a grid of module centers before proceeding to the grading itself).

 

The rest of ISO/IEC 15415 consists of evaluating parameters based on the reflectance values throughout the symbol, most of the time at the module center locations.  For example, MODULATION (and RM) is graded based on the reflectance levels of each of the data modules within the blurred (reference) image at the module centers.

 

So, the refrain is: “if only the reference decode algorithm would succeed on dot printed symbols (the term I will use to refer to matrix symbols that are printed with a dot for each module that is not necessarily connected to neighboring dots), then the symbol would pass the grading criteria of ISO/IEC 15415.”  In this way, it is not ISO/IEC 15415 that is biased against dot printed symbols the original source.  However, the symbology specifications clearly are biased against dot printed symbols.

 

We introduced the stick algorithm into AIM DPM which addresses this problem directly.  We also introduced many other grading based modifications into AIM DPM. The stick algorithm would address the issue of non-connected dots for symbols whether those symbols are dot-peened or otherwise “called” DPM symbols or not.  For example, an ink jet process may create dot printed symbols and could be decoded using the stick algorithm and then graded according to the “normal” ISO/IEC 15415 rules and it could pass.  It does not “need” the other DPM related CM and CC related grading processes in order to pass.

 

There is no facility in ISO/IEC 15415 to use a stick algorithm to grade a symbol.  There is no facility within any symbology specification to use a stick algorithm as part of its reference decode algorithm either, but it would be easy to introduce this.  This change might be very disruptive to existing equipment and therefore, such a change would surely “create” a dot printed version of a symbology since symbols that would be undecodable before, may now obtain a passing grade once the stick algorithm were used in the reference decode algorithm.  However, there is nothing preventing a version of a symbology being created (such as Dot QR or Dot Data Matrix, just like there is Micro QR and Micro PDF 417) which could utilize this technique.

 

I believe this should be considered – to introduce dot versions of the symbology within the symbology specification that uses a reference decode algorithm that can succeed on dot printed symbols.  (The stick algorithm is only one way to do that, you could introduce other reference decode algorithms to decode such symbols but no one was willing to contribute what amounted to a proprietary technique for decoding dot-peened symbols to the standardization effort and that is why I contributed the stick algorithm in the first place).  For reasons of compatibility, I don’t know if such a change to a symbology specification would be well advised, but it seems to me that an application specification should have the power to do so.  I think that currently, it is well that this technique is well differentiated from “standard” symbols because of DPM grading according to AIM DPM being prefaced with “DPM” so that only applications which specifically call for it will allow it.  By the way, I do not think the “additional grading criteria” clause could be construed to allow an application specification to add the stick algorithm to the reference decode.  Perhaps this power for application specifications can be added, with a corresponding notation such as “DOT” before the grade, in future revisions to 2D matrix symbology specifications.