16

さて、私はこのOCRのコンパイルされた.NETバージョンを使用しています。これは@ http://www.pixel-technology.com/freeware/tessnet2/で見つけることができます

私はそれを機能させていますが、これの目的はナンバープレートを翻訳することです.悲しいことに、エンジンは実際にはいくつかの文字を正確に翻訳しません.たとえば、これは文字の問題を特定するためにスキャンした画像です.

ここに画像の説明を入力

結果:

12345B7B9U ABCDEFGHIJKLMNUPIJRSTUVHXYZ

したがって、次の文字は正しく変換されていません。

1、O、Q、W

これはそれほど悪くはないようですが、私のナンバープレートでは、結果はそれほど良くありません:

ここに画像の説明を入力= H4 ODM

ここに画像の説明を入力= LDH IFW

偽のテスト

ここに画像の説明を入力= NR4 y2k

お分かりかもしれませんが、ノイズ リダクション、コントラストの増加、完全な黒ではないピクセルの削除を試しましたが、実際の改善は見られませんでした。

エンジンの新しいフォントを「学習」できるようですが、ライブラリを .NET 用に再コンパイルする必要があると思います。これは、私が持っていない Linux OS で実行されているようです。

http://www.scribd.com/doc/16747664/Tesseract-Trainingfor-Khmer-LanguageFor-Posting

だから私は次に何をしようか迷っています。誰かがそれを試してみたいと思っている場合に備えて、純粋にテスト目的で簡単なコンソールアプリケーションを書きました。アイデア/グラフィック操作/ライブラリの考えがある場合は、聞いていただければ幸いです。

4

7 に答える 7

28

私は最近、Tessnet2 経由で Tesseract を使用しました (よく覚えていれば、Tessnet2 は、Rémy Thomas によって作成された Tesseract 2.0 の VS2008 C++ ラッパーです)。このツールに関して私が持っている少しの知識であなたを助けようとしましょう:

  • 第 1 に、上で述べたように、このラッパーは Tesseract 2.0 専用であり、Google Code の最新の Tesseract バージョンは 3.00 です (コードは Source Forge でホストされなくなりました)。定期的な貢献者がいます: バージョン 3.01 かそこらが計画されているのを見ました。そのため、ナンバー プレートが 100% 水平でない場合に役立つ可能性のあるページ レイアウト分析など、最後の機能強化の恩恵を受けられません。

  • バージョン 3 の Tessnet2 .NET ラッパーを Rémy に依頼しましたが、彼は今のところ何も計画していません。私がしたように、あなたは自分でそれをしなければなりません!

  • したがって、ソースの最新バージョンを入手したい場合は、Subversionリポジトリからダウンロードして (すべて専用のサイト ページに記載されています)、Visual Studio 2008 があればコンパイルできます。vs2008サブフォルダー内の VS2008 ソリューション。このソリューションは VS2008 C++ プロジェクトで作成されているため、C# で結果を取得するにはtessDll、プロジェクトによってビルドされた .NET P/Invoke を使用する必要があります。繰り返しますが、これが必要な場合は、興味のあるコード例を用意していますが、C++ にとどまり、独自の新しい WinForm プロジェクトを作成することもできます。

  • コンパイルが完了すると (大きな問題は発生しないはずですが、何か問題があれば教えてください。私もそれらに遭遇した可能性があります :-))特定のトレーニング!繰り返しますが、Tesseract 3 トレーニング専用のページがあります。このトレーニングのおかげで、次のことができます。

    • 文字セットを制限すると、句読点が自動的に削除されます (たとえば、「A」ではなく「/-\」)

    • トレーニングを使用するときに考慮される、検出したあいまいさを示します (ご覧のように「O」の代わりに「D」、「8」の代わりに「B」など)。

  • また、文字が配置されているゾーン (つまり、顔がなく、周囲に風景がない) に画像を制限すると、Tesseract の結果が向上することもわかりました。私の場合、ウェブカメラから撮影したカードの写真の特定のゾーンのみを認識する必要がありました。ということで、画像処理でゾーンを抑えました。もちろん、それは長かったのですが、私のイメージはさまざまなソースから来たので、選択の余地はありませんでした。最小限に抑えた画像が撮れたら最高です!

ご意見やご質問がございましたら、お気軽にお寄せください。

于 2011-02-08T09:24:20.227 に答える
11

こんにちは、私は tesseract で多くの ocr を実行しましたが、あなたの問題もいくつかありました。画像処理ツールについて質問された場合は、 「unpaper」をお勧めします (Windows ポートもあります。Google を参照してください)。ocr'ing の前に実行するのに最適です。

画像の背景色が(多少)変化する場合は、「textcleaner」imagemagickスクリプト をお勧めします。これは、エッジを検出し、エッジのないものをすべて白くするものだと思います。

また、複雑なテキストがある場合は、「ocropus」が役立つ可能性があります。構文は (Linux の場合): "ocroscript rec-tess "

私のセットアップは 1.textcleaner 2.unpaper 3.ocrups です。

この 3 つのステップで、ほとんど何でも読むことができます。不均一な照明で撮影された非常にぼやけたノイズのある画像でも、2 列のテキストがぎっしりと詰まっているため、非常に読みやすくなります。あなたのニーズはそれほど多くのテキストではないかもしれませんが、ステップ 1) と 2) は役に立つかもしれません。

于 2011-02-13T22:40:22.893 に答える
3

私は現在ispyのナンバー プレート認識エンジンを構築しています。

W

4

M

tesseract の大きな問題は、水平方向の文字と数字から単語を作成しようとすることであり、文字と数字が混在するナンバー プレートの場合、数字が文字であるか、またはその逆であるかを判断します。文字を縦に並べて画像を入力すると、テキストではなく個々の文字として扱われます。

于 2011-08-23T13:19:02.493 に答える
2

素晴らしい読み物!http://robotics.usc.edu/publications/downloads/pub/635/

ナンバープレートのスキュー問題について:

問題:OCR入力がハンドヘルドカメラまたはスキャナーのように遠近法が固定されていない他のイメージングデバイスから取得されると、テキスト行が元の方向から歪む可能性があります[13]。私たちの実験に基づくと、このような回転した画像をOCRエンジンに送ると、非常に悪い結果になります。提案されたアプローチ:認識エンジンを呼び出す前に、スキュー検出プロセスが必要です。スキューが検出されると、自動回転手順が実行されてスキューが修正されてから、テキストがさらに処理されます。スキュー検出に使用するアルゴリズムを特定しているときに、[13]で説明したような多くのアプローチは、ドキュメントにマージンがあるという仮定に基づいていることがわかりました。ただし、この仮定は、アプリケーションで常に当てはまるとは限りません。加えて、形態学的操作と投影法に基づく従来の方法は非常に遅く、カメラでキャプチャされた画像が存在すると失敗する傾向があります。この作業では、スキュー検出と自動回転のために、BranchandBoundテキストライン検出アルゴリズム(RASTアルゴリズム)[25]に基づくより堅牢なアプローチを選択します。このアルゴリズムの基本的な考え方は、各線を個別に識別し、テキストセグメント全体のスキュー角度として最高スコアの線の傾きを使用することです。スキュー角を検出した後、それに応じて回転が実行されます。私たちの実験に基づいて、このアルゴリズムは非常に堅牢で、非常に効率的で高速であることがわかりました。ただし、30を超える回転を検出できなかったという意味で、1つの小さな制限がありました。別のアプローチも試しました。これは、最大90度のスキューの角度を検出できます。ただし、このアプローチは、画像上のある種の十字の存在に基づいていました。拡張性がないため、RASTアルゴリズムを使用することにしました。

于 2012-05-22T11:53:48.650 に答える
0

ABCocr .NET は Tesseract3 を使用するため、.NET で最新のコードが必要な場合に適している可能性があります。

于 2013-01-16T09:04:15.373 に答える