コンテンツにスキップします。

さまざまな言語の精度率については、DAS チュートリアル 2016 のテストセクションを参照してください。


Google データ センターの巨大なテスト (ヒンディー語?)

エンジン 文字全体エラー 単語リコール エラー 単語精度エラー ウォールタイム CPUtime*
Tess 3.04 13.9 30 31.2 3.0 2.8
Cube 15.1 29.5 30.7 3.4 3.1
Tess+Cube 11.0 24.2 25.4 5.7 5.3
LSTM 7.6 20.9 20.8 1.5 2.5

上の表では、LSTM はウォール タイムと CPU タイムの両方で、(キューブを追加せずに) テス 3.04 よりも高速であることに注意してください。ウォール タイムでは 2 倍の速さです。


HP Z420 の 1 ページのヒンディー語で行ったテストからの 3 回の結果の中央値。

テストモード リアル ユーザー
オリジナル (キューブ + テス) 7.6 7.3
ベース テス 2.9 2.6
Cube 5.4 4.9
OpenMP + AVX を搭載した LSTM 1.8 3.8
AVX を搭載した OpenMP なし LSTM 2.7 2.4
SSE を搭載した OpenMP なし LSTM 3.1 2.7
SIMD を搭載しない OpenMP なし LSTM 4.6 4.1

簡単なスクリーンショットを使った最初の実行テストでは、LSTM で大幅に優れた結果が得られましたが、Tesseract のデバッグ ビルド (-O0) で 16 分の CPU タイム (9 秒の代わりに) が必要でした。リリース ビルド (-O2) では、LSTM で 17 秒、LSTM なしでは同じ画像で 4 秒必要です。

デバッグ時の速度の遅さは予想通りです。新しいコードはメモリの消費量がはるかに多いため、デバッグ時ははるかに遅くなります (デバッグ時は OpenMP も選択によりオフになります)。最適化されたビルド速度は、ラテン語ベースの言語では妥当なようです。ベースの Tesseract よりも高速に実行するのは、複雑なスクリプトです。


参照: https://github.com/tesseract-ocr/tesseract/issues/40