さまざまな言語の精度率については、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