フォトQRコードは本当にスキャンされるのか?当社のデコードテスト結果
写真のようなQRコードはスキャン性能が低下するように思えます。実際のデコーダーで測定しました—ぼやけ、縮小され、リーダーが読む方法で読みました。
このトピックの新機能: 当社のフォトQR実装のデコードテスト結果。jsQRを使用してプレーンコントロールコードと比較:リーダー開口部0.10~0.45モジュールのあらゆるサイズで4,225モジュール中の誤読ゼロ、同一の3倍ダウンスケール許容値、プレーンコードの6ピクセルに対する4~5ピクセルのぼやけ許容値—コードを画像に変えるための特定の小さなコスト。
写真である QR コードは、トレードオフがあるように見えます。美しいですが、スキャン数が減ります。この直感は、ほとんどの実装には当てはまりますが、それが機能する仕組みについては間違っています—また、「いくつかのスキャン」は誰も公開していない数字です。
以下は、機能を出荷する前に合格する必要があったテストスイートからのものです。
# 写真 QR コードは何か、そして何でないか
2つの非常に異なるものが同じ名前で呼ばれます。
AI QR アート— 拡散モデルの種類— QR コードで条件付けされた画像を生成し、結果がまだデコードできることを望みます。時々できます。故障モードは、誰かが暗いバーで 3 年前の電話を向けるまで目に見えません。
ディザされたフォトコードは、もう 1 つのアプローチであり、ここで測定されたものです。画像は誤差拡散によってサブピクセルあたり 1 ビット(黒または白)に縮小されます。1つの重要な制約があります。すべてのモジュール中心で、ディザはエンコーダーが要求する値に強制され、その強制が作成するエラー(暗い領域の白モジュールの場合、ピクセルの価値の約 95%)はまだ閾値処理されていない隣のサブピクセルに押し出されます。画像はモジュール中心の間のスペースで作られます。
この区別が記事全体です。これは、コードが誤り訂正を装飾に費やさないことを意味します。すべてのモジュールはまだエンコーダーの値を持っているため、完全な冗長性は折り目、まぶしさ、1つのコーナーの上の親指—誤り訂正が実際に存在する理由—のために無傷です。
# テスト
以下はすべて、リポジトリからオフラインで再現可能です。
- エンコーダ: 独自の
packages/qr、誤り訂正 H、密度フロアminVersion: 12→ シンボルバージョン 12、65 モジュールにわたり、モジュールあたり 10 ピクセル、4 モジュール静寂ゾーン。 - スタイル: halftone(真のディザされた写真)と mosaic(モジュールのみが描画され、ローカルな暗さでサイズが決定される)に対して、プレーンアンディザコードをコントロールとして—同じペイロード、同じバージョン、同じスケール。
- イメージ: 対角勾配(すべてのトーンが表示される)とフラットミッドグレーを含む手続き型テストイメージ。最悪のケースです。すべての強制ドットが周囲と一致しないためです。
- デコーダ: jsQR 1.4.0、実際の QR デコーダ、実際のピクセルが与えられます。
- 劣化: 最近隣ダウンスケール、ボックスぼかしとそれに続く再閾値処理(ピントが外れたカメラ)、および開口部読み取り。
これが構築されているスイートは packages/qr/test/dither.test.js です。2026-08-31 で 39/39 パスが実行され、デコードに失敗するコードは警告ではなく失敗テストです。そのルールが、機能がこの形で存在する理由です。以下の表は draft/mostlyqr/seo/benchmarks/photo.js で印刷され、同じスタイルを同じ劣化で実行します。ここに転記されたものはありません。
# すべての開口部で、ゼロ誤読モジュール
最も重要な測定値は「デコードしたか」ではなく、「読者がすべてのセルで正しい値を見たか」です。なぜなら、誤り訂正によってのみデコードされるコードは、他の何かが失敗すると失敗するコードだからです。
準拠する読者は、モジュールごとに 1 ピクセルをサンプリングしません。各モジュール中心で小さな円形の開口部を平均化し、その平均を閾値処理します。そこで、開口部半径 0.10、0.25、0.36、0.45 モジュール(0.5 がモジュール全体)で同じことを行い、4,225 モジュールのうち何個が間違って読まれるかを数えました。
| スタイル | 誤読モジュール、開口部 0.10 / 0.25 / 0.36 / 0.45 |
|---|---|
| plain code (control) | 0 / 0 / 0 / 0 |
| mosaic photo | 0 / 0 / 0 / 0 |
| halftone photo (gradient) | 0 / 0 / 0 / 0 |
| halftone photo (flat mid-grey, worst case) | 0 / 0 / 0 / 0 |
あらゆるスタイル、あらゆる開口部で、1 つのモジュールもありません。フォトコードとプレーンコードは、読者に同じ値を提示します。誤り訂正は触れられず、完全に利用可能なままです。
# コスト:ぼかしの約 1 ステップ
未処理の誤り訂正は同一を意味しません。ディザはモジュール中心の間のピクセルがどのように見えるかを変えます。ピントが大きくずれたカメラはそれらのピクセルを一緒に平均化します。だから私たちは各スタイルを壊れるまで押しました。
| スタイル | まだデコードされた最大ダウンスケール | まだデコードされた最大ぼかし半径 |
|---|---|---|
| plain code (control) | 3× | 6 px |
| mosaic photo | 3× | 5 px |
| halftone photo (flat mid-grey) | 3× | 6 px |
| halftone photo (gradient) | 3× | 4 px |
ダウンスケーリング—ネイティブより小さくレンダリングされたコード—はすべてのスタイルで同一です。各々は 3× を生き残り、各々は 4× で最初に失敗しました。(最近隣ダウンスケーリングは単調ではありません—5×で再度デコードされたものもあります。サンプリング グリッドがより親切に着地したとき—したがって、私たちが報告する数字は最後の成功ではなく最初の失敗です。)
ピントが外れるのはコストが表示される場所であり、最も難しい画像のハーフトーンスタイルのみです。プレーンコントロールより 3 分の 1 少ないマージン。フラットミッドグレーフィールドのハーフトーンはプレーンコードと正確に一致したため、これはテクニックの特性ではなく、画像に依存するコストです。簡潔に言うと、フォトコードには、カメラがプレーンコードより約 1 ステップ焦点に近い必要があります。これは実際のコストであり、小さなコストであり、「それらはスキャンしますか?」に対する正直な答えです。「はい」ではなく「いいえ」でもなく、「はい、焦点許容度が約 1 ステップ少ない」です。
モザイクスタイルは 2 つの間に位置します。意味があります。モジュールのみを描画するため、中心の間のインクが少なく、ぼかしがにじむ可能性が低くなります。
# 密度が実際の要件である理由
この機能の最初のバージョンは技術的に正確でしたが、写真 QR ツールを使用している場合に知る価値のある理由で間違っていました。
https://mqr.sh/AB12CD 誤り訂正 H での—フォトコードが強制するもの—は、29 モジュールグリッドにエンコードされます。それは全体の写真のための 841 セルであり、結果は画像ではなくノイズとして読まれます。人々は、テクニックが壊れていると結論づけます。実際の問題は、画像が住む場所がないことです。より密なシンボルを強制することで修正します。
| 最小バージョン | シンボル | モジュール全体 | 画像に利用可能なセル |
|---|---|---|---|
| none (ペイロードが必要とするもの) | v3 | 29 | 841 |
| 8 | v8 | 49 | 2,401 |
| 12 (デフォルト) | v12 | 65 | 4,225 |
バージョン 12 での 5 倍のセル。 すべての真面目なイメージ QR ツールが同じ理由でこれを強制し、フロアはペイロードが実際に必要とするもの以下のシンボルを縮小してはいけません—データは常に密度に勝ちます。
印刷への影響は直接的であり、この記事がペイロードに必要なモジュール数と同じクラスタに位置する理由です。65 モジュールのコードは、その静寂ゾーンを含む 73 モジュール幅の紙が必要です。0.5mm モジュールでは 36.5mm—したがって、フォトコードはポスター、メニュー、パッケージングパネル、またはスクリーンです。ビジネスカードではありません。
# テストがカバーしていないこと
明確に述べられました。なぜなら、述べられていない制限があるベンチマークは何もないより悪いからです。
- 1 つのデコーダ、合成ピクセル。 jsQR は実際のデコーダですが、電話のカメラスタックではなく、入力は印刷された物の写真ではなく、きれいなレンダリング出力です。
- 印刷なし、まぶしさなし、遠近法なし、しわなし。 それらはすべてマージンをコストし、それらはフォトコードとプレーンコードに異なるコストがかかります。
- 色なし。 これらは 1 ビットの白黒コードです。
- 独自の実装。 ここのものは他の誰かの写真または AI アート QR コードについて何も言いません。モジュールを上書きして誤り訂正に頼ってダメージを修復する場合、これのような動作はなく、公正なテストは上記のものを彼らに対して実行することです。
# いつ使用するか
- はい: ポスター、ガラスの下のメニュー、パッケージングパネル、スクリーン、展示グラフィックス、大きく印刷されたすべて。
- おそらく: アルバムカバー、本のジャケット、大きな製品ラベル—テストしてください。
- いいえ: ビジネスカード、折られる紙のチラシ、約 35mm 未満のすべて、遠距離で悪い光でスキャンされたすべて。
そして、あなたが欲しいのが全体の写真ではなく、それ以外は普通のコードの中央のロゴである場合、それははるかに小さい予算を持つ異なるテクニックです—私たちはロゴがどのくらい大きくなるかを測定しました。答えはインターネットが考えるより小さいです。
MostlyQR の写真コードはここで測定された実装です。同じディザリング コアはブラウザプレビューとサーバーレンダリング PNG で実行されるため、ビルダーに表示されるものがプリンターが取得するものです。ビルダー自体のメモは、「スクリーンと大きな印刷に最適—フォトコードは小さいまたはしわくちゃな紙での読み取りが難しい」と言います。これらの数字の後では、言う価値のある正しいものです。
よくある質問
フォトQRコードは確実にスキャンされますか?
当社のテストではそうです—1つの測定可能なコストがあります。適合リーダーが行うように当社のフォトコードを読んで、各モジュール中心で円形開口部を平均化することで、テストしたあらゆる開口部で4,225モジュール中の1つも誤読されませんでした。プレーンコードと同じ3倍ダウンスケール許容値を持ちました。測定された唯一の違いはピント外れであり、最も難しい画像でのみ:プレーンコントロールは6ピクセルのぼやけ半径を生き残り、モザイクスタイルは5、勾配の網点スタイルは4(平らな灰色では6)。これはおおよそカメラフォーカスの1ステップであり、信頼性の異なるカテゴリーではありません。
アーティスティックなQRコードはエラー訂正を使い切りますか?
多くの実装がそうします。これが技術が悪い評判を持つ理由です。当社のものはそうではありません。モジュール全体を画像データで上書きしてReed-Solomonに差の修復を頼る代わりに、各モジュール中心のドットをエンコーダーが要求する値に強制し、結果のエラーを周囲のサブピクセルに拡散します。画像はモジュール中心間のスペースから支払われるため、完全なエラー訂正予算は実世界のために存在します—折り目、眩光、角への親指のために。
チラシにフォトQRコードを印刷できますか?
いいえ。当社独自のビルダーは「スクリーンと大型プリントに最適」と言っており、我々はそれを意味します:フォトコードは密度の高いシンボル(以下のテストで65モジュール、同じ短いリンク非強制の場合は29)が必要なため、チラシサイズではモジュールがすぐに非常に小さくなります。ポスター、ガラスの下のメニュー、パッケージングパネル、スクリーンが正しい場所です。ポケットに折られた紙のチラシはそうではありません。
自分のフォトQRコードが画像ではなくノイズに見えるのはなぜですか?
ほぼ常にシンボルが粗すぎるためです。エラー訂正Hの短いリンクは29モジュールグリッドにエンコードされます—841セル、認識できる画像を運ぶにはあまりにも少なすぎるため、画像が存在する場所がありません。より密度の高いシンボルを強制すると修正されます:バージョン8は49モジュール、バージョン12は65モジュール(4,225セル、5倍)を提供し、ちょうどこの理由で当社のビルダーはフォトコードのバージョン12をデフォルトにしています。データは常に優先されるため、長いペイロードでもより大きなシンボルが得られます。