Tesseractはゆっくりと認識しますか？

各プログラムは少なくとも10倍加速できます



スマートエンジン開発者ワークスペース

OCR Tesseractで認識を高速化するためのいくつかのテクニックについて説明します。 上記のすべては、プロジェクトの実装で使用されました。その意味は、ビジネスドキュメントのページの多数の画像（パスポート、契約、契約、委任状、登録証明書など）を分類し、結果を電子アーカイブに保存することでした。 分類アルゴリズムの一部はページの実際の画像の分析に基づいており、一部は画像から抽出されたテキストの分析に基づいていました。 テキストを抽出するにはOCR認識が必要でした。

プロジェクトの機能（完成品の購入では取得できない、事前設定されたプロパティを持つソフトウェアまたはハードウェアとソフトウェアの複合体を作成するために設計されたカスタム作業）は、請負業者の時間制限とリソース制限の存在です。 言い換えれば、プロジェクトでは、請負業者は常に自分が適切と考える問題を解決する能力を持っているわけではなく、期限やその他の制限を満たしつつ必要な機能を達成できる妥協案を探すことを余儀なくされています。 このプロジェクトでは、8時間で60,000ページを認識する方法をすばやく見つける必要がありました。 さまざまな理由から、無料のテキスト認識ソフトウェアを使用し、OCR Tesseractを選択しました。 選択の基準は、テキスト認識の許容可能な品質であり、後続の分類の品質を保証しました。

システムの完全に機能するレイアウトを組み立てた後（フルテキストOCRに加えて、バーコードを認識し、ドキュメントのページ画像を分析し、ページをインポートして結果をエクスポートする機能がありました）、作成されたソフトウェアはシステムの機能を実証するためでも非常にゆっくりと動作することがわかりました。 たとえば、ドキュメントの100ページのテストパックの処理には1時間以上かかることが判明しました。これは、顧客に見せるためには完璧ではありません。元の100ページが電子アーカイブに送られるまで待ちません。

パフォーマンス分析により、ほとんどの時間がTesseract認識に費やされていることが示されました。 Tesseractのパフォーマンスに関する情報（インターネットと専門家への問い合わせの両方）を検索したところ、多くのユーザーがこのOCRが十分に高速ではないことに気付き、Tesseractを高速化するための推奨事項はプライベートであり、実験的に検証する必要があります。 認識速度を上げるいくつかの方法をテストし、システム全体の大幅な高速化につながった方法について説明しました。

任意のプログラムを加速する方法は、次のようないくつかのグループに分けることができます。

• 使用されるアルゴリズムの最適化。
• 使用されるアルゴリズムのパラメーターの選択。
• 最新のプロセッサ技術を使用したコンパイルの最適化。
• 処理アルゴリズムの並列化。

Tesseract自体を最適化する可能性から始めましょう。 バージョン3.04.00の場合、SSE2最適化を備えたMicrosoft Visual Studio 2013を使用してシングルスレッドシステムを構築するためのプロファイラーが組み込まれているため、Tesseractの合計実行時間の15-25％が1つの関数IntegerMatcher :: UpdateTablesForFeatureに含まれています。 理論的には、この関数はアルゴリズムの最適化の候補ですが、IntegerMatcher :: UpdateTablesForFeature関数のコードが、少なくともデータ編成と処理操作の数の観点から明らかに繰り返し最適化されていることは容易にわかります。 そのような最適化の可能性には、プロジェクトで許容できない時間の消費が明らかに必要であるという結論に達しました。 したがって、より単純な最適化方法に移りました。

使用する主なTesseract APIパラメーターについて説明します。 初期化は高速モードで実行されました（api.Init（）メソッドのtesseract :: OEM_TESSERACT_ONLY）。 一部のドキュメントクラスではページタイトルを分析するだけでは不十分であり、ページの下部で単語検索が必要になるため、ページ領域全体が認識されました。 認識言語「rus + eng」が使用されました。これは、ロシア語と英語の両方の単語を使用して印刷されたビジネス文書に自然に見えます。 ページはカラー画像で表されていましたが、実際には多くのページがグレースケールでした。

これらのパラメータの一部を変更すると、認識が大幅に加速しました。

Tesseractのパフォーマンスは、Intel®Core（TM）i7-4790 CPU 3.60 GHz、16.0 GB、4つの物理コアと8つのHTコアを備えたWindows 7 prof 64ビットで評価されました。 以下に説明するすべての実験では、さまざまなタイプ、さまざまな色（グレースケールとカラー）、さまざまな解像度（150から300 dpi）、さまざまな品質（クリーンでノイズの多い）、およびさまざまなページあたりの文字数。 Tesseractのパフォーマンスは、1ページの認識時間の直接測定を使用して評価されました。

初期パラメーターを使用した300ページすべての認識にはt = 4928.53秒かかり、1ページt _cpの平均認識時間は16.43秒、1ページの最小認識時間t _min = 0.99秒、最大t _max = 143秒でした。 21秒 0〜150の範囲で10秒の時間間隔を検討します。認識時間のばらつきは、間隔のいずれかに該当する認識時間を含むページ数のヒストグラムで示されます。

同様に、対応する間隔からのすべてのページの認識に費やされた合計時間のグラフ：

定性的に大きな散布は、テストセットのさまざまなページ画像によって説明されます。 考慮されたページのセットでは、多くの文字または文字に類似したオブジェクトを含むページに最大の時間が費やされます。

高速化するために、まず認識言語を「rus + eng」から「rus」に変更しました。 これは、キリル文字で印刷された単語のみの分析で構成される、さらなる分類のためのアルゴリズムの変更により可能になりました。 パフォーマンスの向上がどうなるか見てみましょう：合計時間t = 3262.33秒、1ページの平均認識時間t _cp = 10.87秒、1ページの最小認識時間t _min = 0.99秒、最大t _max = 83.07 。

その結果、各ページの認識ゾーンが制限されました。 これを行うために、約5,000ページのトレーニングセットで、分類に必要なすべてのキーワードがこの領域にあるという制限を選択し、わずかなマージンで、ページの高さ70％、幅90％の制限を選択しました。 当然、この制限により、Tesseractはより速く認識し始めました：合計時間t = 2649.57秒、1ページの平均認識時間t _cp = 8.83秒、1ページの最小認識時間t _min = 0.83秒、最大t _max = 77.64。

両方のパラメーターの変更はプロジェクトの仕様の結果としてのみ可能になったことに注意してください。他の条件ではこれが機能しない場合があります。たとえば、入力ストリームに英語のドキュメントがある場合、認識言語は「rus + eng」のままにする必要があります。

しかし、そのような幸運の後、ページ処理を高速化するためのアルゴリズムを探し続けました。 認識前にページ画像を二値化する手順は非常に効果的であることが判明しました。 二値化の最初の目標は、複雑な背景と形態学的操作の除去による認識精度自体の改善を検討したことです。 しかし、二値化も良好な加速を与えました：t = 2293.20 s、t _cp = 7.64 s、t _min = 0.98 s、t _max = 59.83 s。 これらの時間は、単一言語「rus」、インストール済みフレーム0.7x0.9、および予備2値化の認識の場合に取得されました。 所定の時間には、Tesseractの合計認識時間と2値化の時間が含まれることを強調します。

二値化は、認識の高速化と認識精度の向上の両方を可能にする普遍的な手法であると想定しています。

次に、コンパイルを使用した最適化について説明します。 以前のすべての実験は、Visual Studio 13コンパイラー（バージョン12.0.40629.00 Update 5）を使用して実行されました。 インテルC ++コンパイラーXE 15.0でコンパイルすると、2値化、フレーム、および1つの言語を使用した以前のバージョンと比較して、高速化が得られました。t= 2156.00秒、t _cp = 7.19秒、t _min = 0.76秒、t _最大 = 59.66秒 AVX2アーキテクチャの最適化オプションがコンパイラに指定されました。 SSE4.2アーキテクチャの場合、結果はほぼ同じですが、AVX2アーキテクチャの結果より優れているわけではありません。 インテルコンパイラーは、Tesseractだけでなく、システムで使用される他のすべてのコンポーネントのパフォーマンスを最適化できることをここで言及する必要があります。

さらに、たとえばTessBaseAPI :: ProcessPagesメソッドの場合、1ページの認識時間を制限するタイムアウトの設定を使用できます。 次に、タイムアウト値が30,000ミリ秒の場合、結果が得られます。t= 2087.10、t _cp = 6.96、t _min = 0.76秒、t _max = 30.00秒。 ただし、タイムアウトによって拒否されたページを分類できないことに関連して観測された損失の2つの理由により、この最適化方法を放棄しました。

明確にするために、説明した実験の結果を表に保存しました。

いや	最適化方法	総時間 t（秒）	平均時間 t cp （秒）	最短時間 t 分 （秒）	最大時間 t max （秒）
1	ソースバージョン	4928.53	16,43	0.99	143.21
2	「rus + eng」の代わりに言語「rus」	3262,33	10.87	0.99	83.07
3	認識ゾーン制限付きのオプション2	2649.57	8.83	0.82	78.38
4	事前二値化のオプション3	2293.20	7.64	0.98	59.83
5	AVX2コンパイラ用に最適化されたオプション4	2156.00	7.19	0.76	59.66

表から、採用された最適化方法（オプション5）の結果として、すべてのページの合計認識時間が元のバージョンの合計時間に対して2倍以上減少したことがわかります。 同時に、選択された2値化アルゴリズムにより、認識の品質とページコンテンツのその後の分析が改善されました。 この処理により、8時間以内におよそ8 60 60 / 7.19≈4005のページ数が認識されます。

次の図では、考慮されるすべての最適化オプションについて、認識時間が10秒間隔のいずれかに該当するページ数のヒストグラムと、同じ間隔のすべてのページの認識に費やされた合計時間のグラフが示されています。

オプション4および5のグラフで、発生した時間の頻度を1秒間隔に分けて検討してください。 このグラフは、AVX2アーキテクチャの最適化により、すべての間隔でページ認識時間が短縮されることを示しています。

オプション4および5の場合、Tessractの合計動作時間の値（表の前に認識と2進化の合計時間の値が示されています）は2091.86および1993.27秒です。つまり、AVX2アーキテクチャの最適化によりTesseract自体が約5％加速されます。

大量のページの認識は、スケーリングなしでは整理できないことは明らかです。 スケーリング時には、マルチスレッドとマルチプロセッシングの両方を使用しました。 同時に、コンピューティングモジュールの負荷分散アルゴリズムにも重要な注意が払われました。 このシステムは、MPIを使用せずに独立して実装されました。 以前に使用したコンピューターと一致する1つのノードで300テストページすべての処理実験（Tesseract認識だけでなく、他のすべてのタイプの処理）を実行し、300ページすべての処理時間tを評価します。 結果は表にまとめられています。

プロセス数	プロセス内のスレッドの数	合計時間t（秒）	平均時間t cp （秒）
1	1	2361	7.87
1	2	1318	4.39
1	3	829	2.76
1	4	649	2.16
2	1	1298	4.33
2	2	789	2.63
2	4	485	1,62
2	8	500	1,67

表から、2つのアプリケーションが起動され、それぞれがページを処理するための4つのストリームが作成されるときに、最良の結果（1ページの処理あたり1.62秒）が達成されることがわかります。 この時間は、次の8時間以内におよそ8 60 60 / 1.62 = 17778のページ数が認識される場合に対応します。 つまり、ページ処理速度が約10倍になりました。 宣言された60,000ページのボリュームを8時間で処理するには、4つの同様のノードが必要です。

もちろん、同様のプロジェクトでは、並列化が処理速度を向上させるための最も効果的なツールであると主張できますが、説明した最適化作業により、処理をさらに2倍、または同じようにノード数を2倍減らすことができました。

結論として、十分な空き時間と十分なリソースがあれば、「原則」を実行することに興味がある実験と研究をリストします。

• 関数IntegerMatcher :: UpdateTablesForFeatureを変更して、Tesseractのパフォーマンスを手動で最適化できるかどうかを調査します。
• Xeon Phiプロセッサ上のAVX512アーキテクチャでテストします。
• Tesseract GPUパフォーマンス最適化オプションをご覧ください。