27  1Dおよび2Dバーコード認識

ここまで、本書のアルゴリズムは「対象はどこにあるか」「寸法はどれくらいか」「欠陥があるか」という問いに答えてきた。本章から始まる認識編は、異なる問いに答える：画像に何が書かれているか――画素を再びデータに戻す。現場で最も成熟し、最も大規模な「画像からデータへ」の応用がバーコードである：各ワーク、各基板、各材料箱にコードが貼付または刻印され、ラインの各ステーションで1回ずつ読み取られ、サプライチェーン全体のトレーサビリティ体系はこの読み取りの積み重ねの上に構築される。コード読み取りは簡単に聞こえる――誰もがスマートフォンでコードをスキャンする――が、生産ライン上のコードはインクの広がり、レンズのピンボケ、低解像度、汚損によって次々と苛まれ、1回の誤読が引き起こす部品混入事故は、読み取り不能よりもはるかに高くつく。本章では、1枚の実機マルチシンボル1Dバーコードテストカード（図 27.1）を用いて、1Dバーコードデコード、劣化に対するロバスト性の境界、2Dバーコードの誤り訂正比較、印字品質評価の4つの実験群を貫き通し、最後に「手書きエンコーダ＋SDKデコーダ」のクローズドループ実験で締めくくる。

図 27.1: 実機マルチシンボル1Dバーコードテストカード sample/barcodes.jpg（1536×878 グレースケール）：8種のシンボル体系、計9個のシンボルを収めた標準テストカード――上段はCODE39とCODE128がいずれも”SCIMV”をエンコード、EAN-8が12345670をエンコード；中段はEAN-13が1234567890128をエンコード、UPC-Aが185020919621をエンコード、UPC-Eが01234565をエンコード；下段はCODE93が”Sci-Code93”をエンコード、2つのITF（Interleaved 2 of 5）がいずれも123456789013をエンコード。赤枠と赤ラベルはSciVision FindBarcodeの検出結果の重ね合わせ（シンボル名＋デコード文字列）。

27.1 1Dバーコードの原理

1Dバーコード（1D barcode）のエンコード思想はきわめて素朴である：バー（bar）とスペース（space）の幅の並びでデータを担う。最も細いバー/スペースの幅をモジュール（module）と呼び、それ以外の要素の幅はモジュールの整数倍となる。1文字は固定数のバーとスペースで構成され、太細の組み合わせがその文字のコードである。情報は一方向にのみ展開され、垂直方向の各行は同じ内容である――これは1本のスキャンラインでデコードできる理由であると同時に、ロバスト性の弱点の根源でもあり、セクション 27.2 でこの点は非常に具体的になる。

代表的なシンボル体系（symbology）はそれぞれ分担を持つ：CODE39は9個の要素（5バー4スペース、うち3個が太要素）で1文字をエンコードし、数字と大文字アルファベットをサポートし、構造が単純で可変長であり、産業用ラベルで極めて一般的である――ただし、そのチェックキャラクタはオプションであり、規格では必須とされていない点に注意が必要である。CODE128はより高密度で、全ASCIIをサポートし、チェックキャラクタを必須で含む。EAN-13/EAN-8/UPCは小売商品コードであり、固定長の数字で末尾がチェックデジットである。CODE93はCODE39の高密度改良版である。ITF（Interleaved 2 of 5）は数字のみをエンコードする連続型シンボル体系である――バーとスペースの両方が情報を担い、文字間に隙間がないため高密度だが、チェックデジットもやはりオプションである。図 27.1 のテストカードはこの8種のシンボル体系を並べており、劣化下での体質差を比較するのにちょうどよい。

CODE39とITFの各要素には一定の「自己チェック」性がある――単一の太細判定ミスは通常不正なコードワードに落ちて破棄される；しかし文字列全体としては必須のチェックキャラクタ（check character）がないため、文字レベルの切り詰めや置換は検出されない。ITFはさらに連続型シンボル体系であり、密度が最も高い。この潜在的リスクは セクション 27.2 におけるITFの複数回の誤読によって裏付けられる。

スキャンラインデコードのプロセスは4つのステップに分かれる：まず画像中でコードを探す――バーコード領域は強い一方向テクスチャを持ち、勾配方向が高度に一致するため、これに基づいて候補領域を迅速に特定し向きを推定できる。次にバーコード方向に沿って1本以上のスキャンライン（scan line）を配置し、グレースケールプロファイルを抽出する。プロファイルにエッジ検出をかけ、バーとスペースの交互パターンを幅の並びに変換する。最後に、シンボル体系のコード表に照らして幅の並びをテーブル参照して文字に復元し、スタート/ストップキャラクタ（CODE39では *）とチェックキャラクタ（存在する場合）を検証する。

図 27.1 にSDKの FindBarcode を実行すると（完全なプロジェクトは code/barcodes/ を参照；barcodeType に「自動」モードがないため、サンプルでは8種の候補シンボル体系を順に試して結果をマージする）、クリーン画像上の9個のシンボルはすべて1回でデコードされ、方向はいずれも0°に近く（カードは水平に配置）、モジュールあたり画素数（pixelPerModule）は2.1～4.1 px/モジュールの範囲に収まる――CODE93が最も細く（約2.1）、EAN-8が最も太い（約4.1）。同時に checkQuality をオンにするとISO/IEC 15416の印字品質評価が得られ、その差は極めて顕著である：EAN-8とUPC-Eは満点の 4.0、CODE93は 3.0（変調度 modulation に制限）、CODE39とEAN-13は 2.0、CODE128とUPC-Aは 1.0（いずれも復号性 decodability に制限）、そして2つの ITFは評価0.0（Fランク）――復号性が0であり、幅の測定値はコード表の判定境界に張り付いており、余裕がほとんどない。復号性は幅の測定値が判定境界からどれだけ離れているかを反映し、変調度は細要素における局所コントラストを反映する。同一のカード上で最も良く印字されたコード（EAN-8）と最も悪いコード（ITF）は丸4ランクも違う――これこそが評価体系の価値である：評価が測るのは「今回は読めたか」ではなく「読めなくなるまであとどれくらいか」である。

ISO/IEC 15416は1Dバーコードの印字品質を4（A）から0（F）までランク付け（grading）する：複数のスキャンラインについてそれぞれデコード、コントラスト、変調度、欠陥、復号性などのパラメータを測定し、各ラインで最も悪いパラメータをそのラインの評価とし、さらに各ラインの平均をとる。総合評価が≥1.5であれば通常は安定して読み取れるが、余裕はすでに大きくない。

評価体系の価値は次の点にある：「今回は読めたか」ではなく、「このコードは読めなくなるまであとどれくらいか」を答えることである。今日読める1.0ランクのコードは、レンズを変えたり少し汚れれば読めなくなる。生産ラインの検収時にラベル評価≥2.5または3.0を要求することは、「現場での試し読み成功」よりもはるかに信頼できる基準である。

27.2 ロバスト性の境界

デコード成功は出発点にすぎず、エンジニアリング上は境界がどこにあるかがより重要である。図 27.1 の9個のシンボルに対し、ガウシアンぼかし、加法ノイズ、ダウンサンプリング、オクルージョンの4種類の漸進的劣化を同時に加え、各シンボル体系の生存と誤読の状況を段階的に記録した（図 27.2 は4つの代表的なレベルを示す）。

(a) ガウシアンぼかし \(\sigma=2\)：9コード中6個がまだデコード可能、CODE93と2つのITFが失敗、さらに1つの ITFが120000000013と誤読された
(b) ノイズ \(\sigma=30\)：UPC-Aのみが失敗、残り8コードは正常（\(\sigma=10\)では9コードすべて正常）
(c) 縮小 ×0.35：CODE39/CODE128（“SCIMV”）とEAN-8のみが読み取り可能、残りは約1.5 px/モジュールを下回り失敗
(d) 全高の白帯が各コード幅の10%をオクルージョン：9コードすべて失敗（赤枠がオクルージョン帯の位置を示す）
図 27.2: 1Dロバスト性実験の4つの代表レベル（赤い重ね合わせは検出/オクルージョンマーク）。完全な境界：ぼかし \(\sigma=1\) で全数正常、\(\sigma=2\) で6/9生存、\(\sigma=3\) で全滅；ノイズ \(\sigma=10\) で全数正常、\(\sigma=30\) で8/9生存、\(\sigma=50\) で6/9生存；縮小 ×0.5で6/9生存、×0.35で3/9生存、×0.25で全滅；全高白帯オクルージョン 2%で6/9生存、5%で2/9生存、10%で全滅。

4つの境界はそれぞれ意味を持ち、かつクリーン画像上の評価順序を項目ごとに裏付けている――評価の低いコードが先に倒れる。ぼかし：\(\sigma=1\) で9コード全数正常、\(\sigma=2\) で6/9生存、先に陥落したのはまさに最もモジュールの細いCODE93（約2.1 px）と2つのITF（約3.0 px）、\(\sigma=3\) で全滅――ぼかしは細バーと細スペースのコントラストを平坦化し、最も細いコードが先に死ぬ。これは15416評価でITF/CODE93がもともと最下位であった予言にちょうど合致する。ノイズ：\(\sigma=10\) は無害、\(\sigma=30\) ではUPC-Aのみが脱落、\(\sigma=50\) でも6/9が生存――複数のスキャンラインはランダムノイズに対して天然の平均化効果を持ち、余裕はかなり大きい。解像度：縮小 ×0.5で6/9生存、×0.35では最も太く最も安定した3コードのみが残る（2つのSCIMVとEAN-8、元のppmは約3.7～4.1、縮小後≈1.3～1.4 px/モジュール）、×0.25で全滅――1Dデコードはスキャンライン上でバー/スペースの幅を識別するだけでよいため、解像度の要求は直感よりもはるかに緩く、約1.5 px/モジュールが本例での実用下限であり、最も細いCODE93はダウンサンプリングの瞬間に真っ先に死ぬ（レンズと解像度の選定は チャプター 3 を参照）。

一文字ずつ読む価値があるのは、どのコードが読めないかではなく、読み間違えたものである。ぼかし \(\sigma=2\) で1つのITFが失敗を報告せず、120000000013とデコードされた（真値は123456789013）；2%と5%のオクルージョンで別のITFが123400789013と誤読された；縮小 ×0.5では本来存在しないEAN-8の誤読45252921まで現れた。トレーサビリティシステムにとって、これは読めないことよりもはるかに危険である：読めなければ手動再スキャンが誘発されるが、気づかれない誤読はあるワークが他人の身分を着たまま生産ライン全体を流れてしまう。根本原因は前述の伏線である――ITF（およびCODE39）のチェックデジットはオプションであり、このカードには付いていない；ITFはさらに連続型シンボル体系（バーとスペースがともに符号化し、文字間に隙間がない）であるため、局所的な汚損が一部を別の合法的な偶数桁の数字列に容易に崩壊させ、シンボル体系レベルでは発見できない。これが、クリーン画像上でも復号性がFランクに留まる理由でもある。工学的対策は2つある：強制チェック付きのシンボル体系を選ぶか（CODE128は本実験を通じて誤読ゼロ）、ITF/CODE39のオプションチェックデジットを有効にし、デコーダ側で codeCheck 検証をオンにするかである；さらに、アプリケーション層で内容フォーマット（桁数、プレフィックス）を検証することは常に価値がある。

オクルージョンはシンボル体系の体質を最もよく区別する：バーコードの全高を貫く白帯を、各コード幅のパーセンテージとして段階的に広げる――2%では9コード中6個がまだ読める（より緩いCODE39/CODE128/EAN系が生存、最も密なCODE93とITFはすでに陥落）、5%ではSCIMVの2個のみが残り、10%ではすべて失敗する。しかし「読める」ことは「正しく読める」ことと等しくない：上記の2回のITF誤読はまさに2%と5%のオクルージョンレベルで発生している。理由は構造的である：1Dバーコードの冗長性は縦方向にのみ存在する――同じ内容がバーの全高にわたって繰り返され、任意の1本の水平スキャンラインがデコードできるため、上下方向からの汚損は致命的ではない；しかし横方向では各文字が1回しか符号化されず、誤り訂正は一切なく、全高の縦方向オクルージョンが1文字を消し去ればその唯一のコピーを消し去ることになる。横方向の損傷に生き残るには、冗長性をデータそのものに組み込む必要がある――これこそがまさに2Dバーコードの設計の出発点である。

27.3 二次元コードと誤り訂正

DataMatrix（ECC200）は、工業部品上で最も一般的に使用される二次元コードである。図 27.3 (a) は 16×16 シンボルである：左側の列全体と下部の行全体が塗りつぶされた L 字型ファインダパターン（finder pattern） を構成し、位置と向きの基準を提供する。上辺の行と右辺の列は白黒が交互に並ぶクロックトラック（clock track）であり、モジュールグリッドの行・列座標を較正する。残りの 14×14 のデータ領域には、ISO/IEC 16022 が規定するジグザグ順序でコードワードが配置され、各コードワードの 8 ビットは「ユタ形」モジュールグループとして配置される。

(a) 手書き ECC200 エンコーダが生成した 16×16 シンボル、内容 “MVBOOK CH27”
(b) シンボル面積の 15% を覆う白いパッチ：誤り訂正予算を超過し、デコード失敗（10% では依然として正しい）
図 27.3: DataMatrix シンボルの構造とオクルージョン実験。(a) 左/下は L 字型ファインダパターン、上/右は交互クロックトラック、内部はデータ領域。(b) 偏心して配置された白いパッチはファインダパターンを避け、データ領域のみを破壊する。面積の 10% は Reed-Solomon 誤り訂正で吸収できるが、15% では失敗する。

二次元コードのロバスト性の核は Reed-Solomon 誤り訂正（error correction） である。直感的には次のように理解できる：12 個のデータコードワードをひとつの多項式の係数とみなし、GF(256) 上で 12 個のチェックコードワードを計算して末尾に付加する——こうして 24 個のコードワード間に強力な代数的制約が生まれ、少数のコードワードが破壊されても、デコーダは制約から逆算して「どれが間違っていて、元の値は何だったか」を推定できる。12 個のチェックコードワードは、位置未知の約 6 個のエラーコードワードを訂正できる——本例では 24 個のコードワードのうちデータが半分を占めるのみであり、シンボル面積の半分が冗長性に費やされている。

Reed-Solomon の誤り訂正予算：\(n_{\text{ecc}}\) 個のチェックコードワードは、位置未知の \(t\) 個のエラーコードワードを訂正でき、\(2t \le n_{\text{ecc}}\) を満たす必要がある。本例では \(n_{\text{ecc}}=12\) であり、したがって \(t \le 6\) である：24 個のコードワードのうち 6 個（25%）が破壊されても完全に復元可能である。

オクルージョン実験は、この「面積でロバスト性を買う」というトレードオフを浮き彫りにする：白いパッチでシンボル面積を覆うと（偏心配置、ファインダパターンを回避）、10% ではデコードが依然として正しいが、15% では失敗する（図 27.3 (b)）。一次元コードと比較すると——最も脆弱な ITF/CODE93 は全高 2% のオクルージョンで陥落し、すべての 1D コードは 10% で全滅し、しかも陥落前に誤読を発生させる——二次元コードは許容量が高いだけでなく、さらに重要なのは密かに読み間違えることがない点である：誤り訂正予算を超過した場合、ReadDM は誤った値を返すのではなく、ただちに失敗（rc=122703001）を返す。さらに、DataMatrix はぼかし \(\sigma=1,2,3\) およびノイズ \(\sigma=30\) の下でもすべて正しくデコードされるが、一次元コードはこれらの水準ではすでに半数が壊滅している（公平を期すために言及すると、本例の DM は約 10.3 px/モジュール であり、テストカード上の 2～4 px/モジュールの一次元コードよりも解像度面で有利であるが、オクルージョンの比較には影響しない）。強調しておきたいが、誤り訂正は無料ではない：同じデータ量に対し、50% の冗長性を持つシンボルは 2 倍の面積を必要とする。二次元コードが面積で購入しているのは、一次元コードがどれほど面積を費やしても買えない横方向の損傷に対する生存能力である。

ついでに QR コードについても触れておく：DataMatrix と同じ「マトリックスコード＋ Reed-Solomon」ファミリーに属するが、主な違いは位置決め方式にある——QR は三つの角に回字型（入れ子四角形）のファインダパターンを用い、DataMatrix は L 字型の実線エッジを用いる。前者は遠距離・大シンボルの高速位置決めに有利であり、後者は小サイズの直接部品マーキング（DPM）用途でよりコンパクトである。SDK は ReadQR インターフェースを提供するが、本章のテスト画像には QR シンボルが含まれていないため、QR の実験は行っていない。原理的な結論は類推により適用できる。

27.4 ラウンドトリップ検証方法論

前節の DataMatrix 画像はどこから来たのか？ここには掘り下げる価値のある方法論的な問題がある：SciVision SDK にはデコード API しかなく、生成 API は一切ないうえ、testImage ディレクトリにも二次元コード画像は含まれていない。二次元コードの実験を行うため、我々はサンプルプロジェクトの中にECC200 エンコーダを手書きした（約 150 行）：GF(256)（原始多項式 301）上で Reed-Solomon 符号化を実装し（生成多項式の根は \(\alpha^1\!\dots\!\alpha^{12}\)）、テキストを ASCII モードで符号化し（数字の 2 桁を 1 コードワードに圧縮、253 状態アルゴリズムでパディング）、ISO/IEC 16022 附属書 F の標準配置アルゴリズムに従って 12+12 個のコードワードを 16×16 シンボルに配置し、ファインダパターンとクロックトラックを付加して画像をレンダリングした。

検証方法はラウンドトリップである：エンコーダが生成した画像を SDK の ReadDM に渡してデコードし、返された文字列を原文 “MVBOOK CH27” と 1 文字ずつ比較する。実験結果：デコードは成功し、内容は一致した。シンボルは 16×16、約 10.3 px/モジュール、ISO/IEC 15415 総合評価 4.0——満点であり、理想的にレンダリングされたシンボルが得られるべき評価である。この往復は両端を同時に検証する：エンコーダが 1 ビットでも誤った位置に配置すれば、デコードは失敗するか誤り訂正余裕が低下するし、SDK デコーダが満点評価を読み出すことは、そのグリッド位置決めと品質測定が正常に動作していることを証明する。これは チャプター 5 における「ゴールドスタンダード実験」の思想の再現である——既知の真値を持つ入力でチェーン全体を検証する——しかもここでの真値は我々自身の手で符号化したものであり、すべてのビットが追跡可能である。同時に、これは 15415/15416 評価のもう一つの使い方も示している：満点評価のシンボルをベースラインとすれば、現場シンボルの評価の低下をパラメータごとに印刷および撮像の各工程に帰属させることができる（照明によるコントラストの問題については チャプター 4 を参照）。

27.5 SciVision 実装

1 次元コードのデコードは SCIMV::SciSvBarCode::FindBarcode で行う：

SCIMV::SciSvBarCode bc;
Sci1DCodeArray codes; SciROIArray rects, bad;   // 3 つの出力すべてに実体を渡す
long rc = bc.FindBarcode(img, roi, SCI_CODETYPE_CODE39,
                         1,      // polarity：暗いバー、明るい背景
                         0,      // sampleRate：自動サンプリング密度
                         2,      // contrastLevel：中コントラスト
                         4,      // codeNumber：期待コード数（コード制ごとのスキャン時に余裕を持たせる）
                         10000,  // timeOut：タイムアウト（ms）
                         0,      // codeCheck：チェックキャラクタ検証スイッチ
                         0,      // decodeDirection：双方向デコード
                         false,  // sendStartEnd：開始・終了文字を出力しない
                         true,   // checkQuality：ISO 15416 評価を出力
                         &codes, &rects, &bad);
// Sci1DCode：codeType / codeString / orientation
//            / pixelPerModule / qualityLevel_15416

3 つのパラメータについて特に説明が必要である。codeCheck をオンにすると、シンボル体系の規則に従ってチェックキャラクタが検証される。CODE39 の場合、印刷側にオプションのモジュロ 43 チェックキャラクタを含めることが要求されるが、これは セクション 27.2 で述べた誤読事故に対するシンボル体系レベルの防御手段である。checkQuality をオンにすると、コードごとに 15416 の各パラメータ評価が出力される。ラインのデバッグおよび受入段階では常時オンにすることを推奨し、安定稼働後は時間を節約するためにオフにしてよい。timeOut はデコードのタイムアウトであり、タクトタイムが厳しいステーションでは必ず設定しなければならない。そうしなければ、1 枚の低品質画像がサイクル全体を引きずり下げるおそれがある。

DataMatrix のデコードには SCIMV::SciSvMatrixCode::ReadDM を用いる：

SCIMV::SciSvMatrixCode mc;
SciDMCodeArray ret; SciVarArray strs; SciROIArray cand;
long rc = mc.ReadDM(img, roi, 1 /*polarity 暗いコード、明るい背景*/, -1 /*dmStyle 自動*/,
                    6, 20,  // minSize/maxSize：シンボルの行・列数の探索範囲
                    30,     // minContrast：最小コントラスト
                    0,      // mirror：ミラーを自動判定
                    1, 10000, 0,            // codeNum / timeOut / model
                    true,   // checkQuality：ISO 15415 評価を出力
                    false, false, false, false, false, false,
                    1, 1,   // デコードおよび出力文字列はともに UTF-8
                    &ret, &strs, &cand);
// SciDMCode：codeString / symbolRows / symbolCols
//            / moduleSize / orientation / qualityLevel_15415

2 つのエンジニアリング上の落とし穴がある。第一に、シンボル体系を明示しなければならない。FindBarcode の barcodeType に「自動」設定はなく、画像中に存在しないシンボル体系を指定するとデコードに失敗する（非ゼロのエラーコードを返す）。シンボル体系が不明な場合は、本章の例のように候補リストをループで試すしかない（ここでは 8 種類の 1 次元コードシンボル体系についてそれぞれ 1 回ずつ FindBarcode を呼び出し、結果をマージして重複を除去する）。ただし、量産プロジェクトでは設計段階でシンボル体系を固定すべきであり、これはラベルサプライヤーと合意する仕様の一部でもある。第二に、SciSvBarCode.h などのヘッダファイルは無条件にエクスポートマクロを dllexport として定義するため、その #include を他の dllimport 形式のヘッダファイルの後ろに配置すれば正常にリンクできる。

業界事例：ライン読み取り率を 98% から 99.9% へ

ある組立ラインの DataMatrix 読み取り率が長らく 98% で停滞していた。決して低くはないように聞こえるが、千個あたり 20 個が手動再スキャンを引き起こすことを意味し、タクトタイムと人件費のいずれの観点からも許容できない。プロジェクトチームはまずデコードパラメータを繰り返し調整したが効果は乏しく、次に検証器でラベルを測定した。変調度は C 評価のみであった——ラベル用紙がインクを吸収してインクの広がりが生じ、狭要素のコントラストが崩れていたのである。同時に光学系を監査したところ、モジュール幅がわずか約 1.8 px/モジュールであり、デコード下限値に張り付いていることが判明した。2 項目の改善策を実施した：高コントラストのラミネートラベル材に切り替えて評価を A/B に回復させたこと、およびレンズの倍率を上げてモジュールを 3 px/モジュールに到達させたことである。読み取り率は 99.9% に上昇し、デコードパラメータは最終的にデフォルト値のままとなった。教訓：読み取り率の問題では、まず印刷品質評価とモジュールあたり画素数を確認し、その後でアルゴリズムパラメータを調整する——評価が不合格のときにパラメータを調整しても、境界線上の賭けにすぎない。

27.6 まとめ

  • 1 次元コードはバー・スペース幅でエンコードし、走査線に沿ってデコードされる。垂直方向にはバー高さ全体の冗長性があるが、水平方向には誤り訂正が一切ない。本章の 8 シンボル体系カードにおいて、最も密な ITF/CODE93 は全高遮蔽 2% で陥落し、すべての 1D コードは 10% で全滅する。解像度の下限は約 1.5 px/モジュールである（×0.35 では最も幅の広い 3 コードのみが生存）。劣化下での生存順序は、クリーン画像の 15416 評価の順序を項目ごとに裏付けている。
  • 誤読は読み取り不能よりも危険である。本カードの ITF（オプションのチェックディジット、連続型シンボル体系）は、ぼかし \(\sigma=2\) および 2%/5% の遮蔽下で複数回の誤読を発生させ（例：120000000013、123400789013）、クリーン画像においても復号可能性は F 評価にとどまる。チェックキャラクタを必須とするシンボル体系を選択する（CODE128 はここでは一度も誤読しない）、codeCheck をオンにする、アプリケーション層でフォーマットを検証する——これら 3 つの防御線のうち少なくとも 1 つは必ず備えなければならない。
  • 2 次元コードは Reed-Solomon 誤り訂正を用いて面積で堅牢性を獲得する。16×16 DataMatrix の 12 個のチェックコードワードは約 6 個の誤りコードワードを訂正でき、面積の 10% が遮蔽されても正しくデコードされる。予算を超えると誤読ではなく失敗を返す——水平方向の損傷に対する許容度は 1 次元コードをはるかに上回る。
  • SDK がデコードのみでエンコードをサポートしない場合、手書きエンコーダと SDK デコーダのラウンドトリップは、実験能力のギャップを埋めるだけでなく、両端に対するゴールドスタンダード検証を構成する（本例のラウンドトリップは ISO 15415 評価 4.0 の満点を達成した）。
  • ISO/IEC 15416/15415 の印刷品質評価が答えるのは「読み取り不能になるまであとどれくらいか」という問いである。受入は試し読みの成功ではなく評価で判断し、読み取り率の問題ではまず評価とモジュールあたり画素数を確認する。

産業ビジョンにおけるバーコード認識およびデコードアルゴリズムのより体系的な議論については、Steger らの著書 (Steger, Ulrich, と Wiedemann 2018) を参照されたい。本章で繰り返し引用した印刷品質グレーディング体系は、2 つの中核規格に由来する。1 次元コードのパラメータ別評価方法は ISO/IEC 15416 (International Organization for Standardization 2016) で規定され、2 次元コード（DataMatrix および QR を含む）のシンボル品質評価は ISO/IEC 15415 (International Organization for Standardization 2011) で規定されている。各シンボル体系のエンコーディング、誤り訂正、および参照デコードアルゴリズムには、それぞれ専用の規格が存在する。DataMatrix（ECC200）のコードワード配置および Reed-Solomon 規則は ISO/IEC 16022 (International Organization for Standardization 2006) に、QR コードは ISO/IEC 18004 (International Organization for Standardization 2015) に規定されている。ラベルサプライヤーと仕様を合意する際や本章の実験を再現する際には、これらの規格の原文を基準とすべきである。