テキストのスキャンについて、みんながアドバイスするアドバイスは、可能な限り最高の解像度を使用して、照明を正しくすることです。 このサイトで、意図的に損傷した一連の画像に対してエンジンを使用して、それらの問題のどれを調べましたか。答えはどちらでもありませんでした。 同じ文は、元のサイズの 3 分の 1 の写真から完全に戻ってきました。灰色の背景に灰色のテキストから完全に、品質 25 で保存された JPEG から完全に戻ってきました。 それが大破したのは、ページを 5 度傾けていた。 以下のすべての数字はその実行から出てきており、通常のチェックリストとは異なるチェックリストを指しています。
tl;dr: Tesseract は、2 つの特定の機能が問題になるまで、きれいにレンダリングされたテキストを読み取ります。 傾きは最初です。0 ～ 3 度のスキューは 0% の文字エラー率、5 度は 2.9%、12 度は 16.7%、20 度は 32.4% でした。 サイズが 2 番目で、傾斜ではなく崖です。テキストは大文字で約 7 ピクセルの高さまで完全に保たれ、その後、5.8 ピクセルで 85.3% のエラーにつぶれました。 低コントラスト、ぼかし、重い JPEG 圧縮はほとんど登録されていません。 他のことをする前に、写真をまっすぐにします。 ザ・ 画像への変換 ブラウザでエンジンを実行するため、画像はアップロードされません。
これらの数値はどのように生成されたのですか?
既知の文をレンダリングし、画像を一方向に損傷して読み返し、結果を修復するために必要な編集をカウントします。
メトリックは文字エラー率です。画像が発言したこととエンジンが返したものの間の距離を、真理値の長さで割った値です。 50 文字の行で 2% のエラー率が 1 文字であるとします。 テキストは、1 つ目のコンテンツではなく 2 番目の種類のコンテンツで実際に重要な間違いが発生するため、散文、請求書番号、日付、通貨量、電子メール アドレス、電話番号を 3 行混在させました。
1 つの警告は、埋もれるのではなく、一番上に属します。 これらはレンダリングされた画像であり、写真ではありません。 1 つずつ、1 つの変数を分離します。これは、原因の原因に帰属します。ページの実際の写真は、わずかな傾き、折り目全体の不均一な照明、片端のモーション ブラー、および保存する前にすべてをシャープにするカメラなど、一度に複数のページを表示します。 したがって、以下のしきい値が最良のケースです。 2 つの軸の限界にある写真は、どちらの数字でも示すよりも悪い結果になります。
エンジンは Tesseract 4 の LSTM モデルで、これはまさにツールが実行するものであるため、別のシステムからの番号ではありません。
どのくらいの歪みが多すぎますか?
3 度から 5 度の間で、あなたが気付くよりも傾きが少ないです。
| ローテーション | 文字エラー率 | 報告された自信 |
|---|---|---|
| 0度 | 0.0% | 95 |
| 1度 | 0.0% | 95 |
| 2度 | 0.0% | 95 |
| 3度 | 0.0% | 94 |
| 5度 | 2.9% | 91 |
| 8度 | 7.8% | 82 |
| 12度 | 16.7% | 70 |
| 20度 | 32.4% | 66 |
3 度の間は何も起こりませんが、棚から落ちます。 その理由は、エンジンの仕組みにあります。それは、テキスト行を見つけて、各行を文字にスライスします。 傾斜した線は数行のピクセルを横断するため、スライスはいくつかの文字の上部と他の文字の下部を切り抜け、モデルは断片を分類するよう求められます。
5 度では、エラーは小さく高価でした。 「日付」は「日付」として戻ってきており、「トータル」は「トータル」として「totg」として戻ってきました。 どちらも、人間が直接読む単語の中にある 1 文字であり、請求書番号と通貨の隣に座って、人がチェックせずにコピーしようとしていました。
ページ上で手で持っている電話は、日常的に 5 度以上離脱しています。 これは、何かを実行する前に修正する価値があります。修正は無料です。線が水平になるまで画像を回転させます。
OCR が失敗する前に、テキストはどのくらい小さくなれるでしょうか?
予想よりも小さく、完全に機能しなくなるまでです。
| 画像幅 | 大文字の高さ | エラー率 | 自信 |
|---|---|---|---|
| 1600px | 〜29px | 0.0% | 95 |
| 800px | 〜14px | 0.0% | 95 |
| 533 px | 〜10px | 0.0% | 92 |
| 400 px | 〜7 px | 0.0% | 84 |
| 320 px | ~6 px | 85.3% | 41 |
| 240 px | 〜4 px | 100.0% | 0です |
同じ 3 行は、元のサイズの 4 分の 1 で完全に読み取られます。各大文字の高さは約 7 ピクセルです。 さらに一歩下がると、出力は使用できなくなり、空になりました。
それは勾配ではなく崖であり、アドバイスを変えます。 「あなたが持っている最高の解像度を使用してください」は間違っていませんが、ほとんどの写真にない問題を説明しています。 Web ページのスクリーンショット、看板の写真、印刷された手紙の電話写真: これらはすべて、7 ピクセルを超える文字の高さを持っています。 彼らがより頻繁に持っているのは傾きです。
崖が噛みつく場所は、遠くから見た作物です。 休日の写真の背景にあるテキスト、通りの向こう側の標識、画面解像度での全ページ スキャン内の小さな印刷の線。 文字が 100% ズームで読みにくい場合、エンジンも床に近づいています。
コントラストが低いと読みが損なわれますか?
いいえ、これは私が期待していたものとほとんど矛盾する結果でした。
#8A8A8A の #8A8A8A の #BDBDBD の灰色のテキストで、エラー率 0.0% と信頼度 95 で、白地に黒と同じで、95 の信頼度を持ちます。 画像全体で 3 ピクセルのガウスぼかしは 0.6% をもたらしました。 品質 25 で保存され、ハーフ サイズにスケーリングされた JPEG は 0.0% でした。
理由は、エンジンがあなたのグレーを読み取らないからです。 最初に画像を二値化し、画像から選択したしきい値ですべてを白黒に変え、均一な低コントラストはそのままのステップで生き残ります。 生き残れないのは、ページ全体で変化するコントラストで、シャドウや電話のフラッシュが生成するものです。1 つのしきい値は、画像の両方の半分に適合することはありません。
したがって、照明アドバイスの有用なバージョンは、通常のものよりも狭いです。 照明も重要です。 明るい照明はありません。 薄暗い、均一に照らされたページの写真は、真ん中に影のある明るい写真を打ち負かします。
2 列のレイアウトがスクランブルで出てくるのはなぜですか?
読み順はレイアウトの判断であり、エンジンはジオメトリだけで構成するためです。
共有ベースラインで、テキストの 2 つのブロックを並べて 3 行ずつレンダリングしました。 結果はインターリーブして戻ってきました:
LEFT ONE RIGHT ONE LEFT TWO RIGHT TWO LEFT THREE RIGHT THREE
すべての言葉は正しいです。 注文は役に立ちません。 エンジンは、3 つの垂直位置にある 6 行のテキストを見つけ、各行を横切って読み取りました。これは、表の正しい動作であり、2 列の散文の場合の動作が正しくありません。
実際の新聞ページやアカデミック PDF は、多くの場合、これは生き残る。コラム間のガターは広く、ページのセグメンテーション ステップで検出できるほど一貫しているからです。 この種のツールの一般的なケースである、2 つの緩いブロックが並んでいるレイアウトのスクリーンショットは、多くの場合、そうではありません。
信頼できる修正は、トリミングすることです。 1 つの列を実行し、結果をコピーしてから、もう一方の列を実行します。 面倒なように聞こえ、約 15 秒かかります。文がシャッフルされた段落を再構築するよりも短い時間です。
筆跡が読めるのか?
信頼できないのは、文字が非公式に見えるかどうかではなく、文字が触れるかどうかに関するものです。
写真を提供しないと実際の手書きをテストできませんでした。これには、変数が混在する可能性があります。そのため、インスタントとして規則性を下げる 3 つのフォントをテストしました。
| フォント | エラー率 | 自信 |
|---|---|---|
| コミックサンズMS | 0.0% | 95 |
| ブラシスクリプトMT | 5.9% | 67 |
| スネルラウンドハンド | 20.6% | 55 |
Comic Sans は非公式で、エンジンに対して完全に読みやすく、文字は幅の異なる形状になっているため、エンジンに対して完全に読みやすくなっています。 Snell Roundhand は接続されたスクリプトであり、文字の 5 分の 1 が間違って戻ってきました。
それが本当の違いです。 Tesseract のモデルは、印刷されたタイプでトレーニングされ、線を個別のグリフにカットすることを期待しています。 コネクテッド ライティングにはクリーンなカット ポイントがないため、認識がチャンスを得る前にセグメンテーションが失敗します。 本物の手書きは、スネルのラウンドハンドよりも悪く、文字ごとに異なるため、良くありません。
手書きの読み書きが必要な場合、これは間違ったツールであり、他のすべての Tesseract フロント エンドも同様です。 その仕事には、手書きの訓練を受けたモデルが必要です。
どのキャラクターが間違っていますか?
数字のように見える文字と方向が一貫しています。
いつもの容疑者の行をレンダリングして、読み返しました。
truth: O0 l1I 5S 8B 2Z rn/m
read: 00 111 5S 8B 2Z rn/m
大文字の O がゼロになりました。 小文字の L と大文字の i はどちらも数字の 1 になりました。 人々が最も心配しているペアは、S に対して 5、B に対して 8 であり、RN に対しても正解でした。
数字の文字の文字が孤立した文字を数字として読み取るパターンです。 散文を実行する際には、これが重要になることはめったにありません。これは、その周囲の言語モデルが結果を単語に引き戻すためです。 参照コード、シリアル番号、またはライセンス プレートでは、周囲に役立つ単語はありません。まさにこの種のツールが使用される場所です。
文字と数字をスペースのない文字列で校正してください。 これは、エンジンが自信を持って間違っている出力の 1 つのクラスです。
信頼度スコアは何を教えてくれる?
あなたが気にかけている数字が正しいかどうかではなく、大まかにページがどうなったか。
このツールは、エンジンの平均語の信頼度を、高、中、低、85 以上で高、高、低として表示します。 測定されたエラー率に対して、マッピングは広く賢明で、エッジで楽観的です。
| 件 | 自信 | ラベル | 実際のエラー率 |
|---|---|---|---|
| クリーン | 95 | 高い | 0.0% |
| 5度の歪み | 91 | 高い | 2.9% |
| 12度の歪み | 70 | 中 | 16.7% |
| 320 ピクセル幅 | 41 | 低 | 85.3% |
| 接続スクリプト | 55 | 低 | 20.6% |
スコアが低いということは、信頼できる警告です。60 歳未満のスコアはすべて、本当に破られました。 スコアが高いということは、見た目よりも弱い証拠です。 5 度のケースでは、インタフェースが高く評価する 91 点を獲得しましたが、請求書の行で静かに単語を壊していました。
保証ではなく、煙警報として使用してください。 低値はわざわざ出力を読み取らないということです。 高いというのは、ページ全体がうまくいったことを意味します。これは、すべての文字が正しいのと同じではありません。
各言語のダウンロード費用はいくらですか?
1 回の 0.67 から 2.82 メガバイトの間で、キャッシュされます。
エンジンには、言語ごとにトレーニング済みのデータ ファイルが必要です。 このツールは LSTM モデルのみを実行するため、整数化された最高品質のセットをプルします。これは、ほとんどの OCR の書き込み引用ファイルよりもかなり小さい値です。 CDN から測定されたライブラリーのデフォルトは、次のとおりです。
| 言語 | ダウンロード | 言語 | ダウンロード |
|---|---|---|---|
| 英語 | 2.82 MB | ヒンディー語 | 1.32 MB |
| ロシア語 | 2.56MB | ベンガル語 | 1.31MB |
| スペイン語 | 2.00MB | 韓国人 | 1.50MB |
| 日本人 | 1.94 MB | ドイツ語 | 1.27 MB |
| 中国語 (簡体字) | 1.64 MB | ポルトガル人 | 1.33 MB |
| アラビア語 | 1.58 MB | イタリア語 | 1.58 MB |
| フランス語 | 0.67 MB |
13 枚すべてが合わせて約 21 MB になり、これは現代の電話からの写真は 1 枚未満です。 中国語または日本語が巨大でなければならないという一般的な仮定はここでは成り立たない。中国語は 1.64 MB で、英語よりも小さい。ファイルはグリフ ライブラリではなくモデルを格納するためです。
1 回目の実行が 2 回目よりも遅いのはなぜですか?
1 つ目はエンジンのダウンロードと始動、2 つ目はただの読み取りのためです。
言語の最初の実行は、Tesseract の WebAssembly ビルドをフェッチし、その言語のデータ ファイルをフェッチして、ワーカーを初期化します。 その後、ワーカーはページ内で生きたままになり、データ ファイルはブラウザによってキャッシュされるため、同じ言語の 2 番目の画像がすぐに開始されます。 言語を切り替えると、ワーカーが再初期化されますが、すでに取得されているものは再ダウンロードされません。
認識自体は迅速です。 このマシンでは、3 行のテスト イメージを読み取るのにクリーン バージョンで 186 ミリ秒、損傷したものでは 70 ～ 125 ミリ秒かかりました。すべてが既に実行中のワーカーで。 テキストのページ全体では、1 秒の 10 分の 1 ではなく 1 秒または 2 秒を期待しますが、最初の実行待ちは、読みではなく設定されています。
言語がキャッシュされると、ツールはネットワークをまったく持たずに機能します。これは、マーケティング ラインではなく、本物のオフライン機能です。
OCR を実行する前に、画像に対して何をすべきですか?
この順番で 3 つのことがあり、最初の 1 つが他の 2 つを合わせたよりも重要です。
- それをまっすぐにします。 テキストの線が水平になるまで回転します。 3 度は無料ですが、5 度は無料です。
- テキストに切り抜きます。 これにより、列の問題が修正され、セグメンタが拒否する必要がある背景が削除され、テキストがフレームのより大きなシェアになります。
- 他のすべてを放っておく。 シャープにしないでください。コントラストを上げないでください。手で白黒に変換しないでください。 とにかくエンジンの二値化が進み、シャープニング フィルターが文字のエッジの周りにリンギングを追加します。
削除するよりも追加する価値があるのは、解像度ですが、それはあなたが床に近づいている場合に限られます。 7 ピクセルの大文字から 14 ピクセルになると、測定値は変わりませんでした。 6 から 7 になると、すべてが変わりました。
OCR が間違ったツールになるのはいつですか?
画像がテキストでない場合、テキストが手書きされている場合、必要なものが文字のブロックではなく検索可能なドキュメントである場合。
OCR は、構造のない単語を提供します。見出しも表のセルも、信頼できる段落境界も、複雑なレイアウト全体での読み取り順序もありません。 スクリーンショットやアドレスの引用から、まさに正しい写真を引用します。 スキャンしたレポートを編集可能なものに変換する場合、これはいくつかの手順の最初の手順です。
必要なのが、印刷された言葉ではなく、写真の説明である場合、それはまったく別のモデルであり、別のツールです。 ソースがスキャンされていない PDF である場合、テキストはすでにファイルに含まれています。直接に引き出すとレイアウトが維持され、何も失われます。これは、画像認識の量に一致しません。
なぜこれがブラウザで実行されるのですか?
人々が OCR に投稿した写真は、最もアップロードしたくないものだからです。
領収書、銀行の手紙、処方箋、パスポート、ID カード、契約書の写真、プライベートな会話のスクリーンショット。 通常の代替手段は、画像を取得し、何も知らないサーバーで処理し、保持するものをすべて保持するサイトです。
ここで、エンジンは、ページのワーカーで実行されています。 画像はタブ メモリにデコードされ、そこに読み込まれ、テキストが表示されます。 何もアップロードされず、キューも保存されていないコピーもありません。最初の実行後は、すべてがオフラインで動作します。 費用は 1 回限りの言語でダウンロードでき、非常に大きな画像はタブの保持範囲によって制限されます。
このサイトではまだ行っていないことの 2 つと同じパイプラインに属している点があります。それは、写真に撮ったページをまっすぐにしてテキストにトリミングすることです。 どちらも、すでに持っているビューアで発生する必要があります。これは、上記のワークフローで 1 つの厄介な継ぎ目です。 後の内容について: ソースが複数ページの写真である場合、 画像の組み合わせのガイド 結果を元に戻すことに対処します。
