web-dev-qa-db-ja.com

スキャンしたドキュメントのどの行にどのテキストが属しているかを推測するにはどうすればよいですか？

スーパーマーケットの領収書の5年間のアーカイブを分析できるようにしたいと考えています。領収書がスキャンされ、Google Cloud Vision APIのおかげで、OCRの結果を利用できます。ただし、GoogleのAPIは、テキストと画像上の幾何学的な位置のみを提供し、それ以上は提供しません。例：

ID: 5620
Content: “TICKET”
Vertices: (2070, 3663); (2069, 3683); (2002, 3680); (2003, 3660)

ID: 5621
Content: “ORIGINAL”
...

次のステップは、テキストの断片を含む一連の行を作成することです。言い換えると、GoogleのAPIが5621が5620の後ろにあることを検出したという事実は、レシートが部分的に回転、湾曲、しわくちゃにされ、壊れている場合があるため、実際にはそうではないということです。次に例を示します。

enter image description here

上部に向かって、右側に価格が記載された3つのアイテムのリストがあります。 2番目の価格3.30€は最初の価格ではなく2番目の価格に対応することを人間が理解するのは簡単です。ただし、そのy座標は、プログラムに、実際には2番目のアイテムではなく、最初のアイテムのテキストに属していると推測させる可能性があります。

それを修正するために、私はこのように進めることにしました：

  1. すべてのテキストについて、GoogleのAPIによって提供された頂点のおかげで、アイテムの回転がわかります。この回転に基づいて、レシートの境界ボックスの左側に投影します。

    境界ボックスは画像上で青色で表示されています。投影は緑の点線で示されています。

  2. 投影された線と交差するテキストのリストを見つけました。

  3. 線と交差するものの中から、右側にあるものを選びます。次に、テキストの前の兄弟としてマークされます。

  4. 以前の兄弟に基づいて、一連のテキストを含む一連のリストを作成します。各リストは行に対応している必要があります。

これらの線は画像上で黒く表示されます。ほとんどの場合に機能するようですが、すべてではありません。たとえば、7、8、9行目は正しいのですが、投影が左側の製品名に到達しないため（10行目は13行目と見なされます）、行10は失敗です。

さらにわかりやすいのは、右下の29行目の「TTC」です。GoogleのAPIはテキストの回転を検出できなかったため、30行目の「TVA」ではなく、左側の「情報」に属するものとして検出されました。同様に、33行目と34行目が絡まっているため、右側のテキストの行は完全に間違っています。

アルゴリズムを調整して、この特定の図でうまく機能するようにすることもできます（そして、上部の3番目の価格が分割されるなどの明らかなバグを修正します。最初の2桁は10行目にあります） 、しかし最後のものは異常に13行目にあるとマークされています、それは退屈なようであり、他のケースでは機能しなくなります。そのような小さな調整が問題を解決する正しい方法だとは思いません。

これらのタイプの問題を解決する標準的な方法はありますか？ここでは人工知能が代替案となる可能性があると思いますが、AIをトレーニングするための入力をどのようにすべきかはわかりません。他に何かできることはありますか？

algorithmsartificial-intelligenceimage-processing
3
Arseni Mourzenko

twocommenters のアイデアは、一般的には最善の策です。これは、ある種の正規化に依存しているためです。問題が扱われます。解決する問題（OCR）の「ヒューリスティック」な性質のため、（あらゆる種類の）ノイズは常に問題を引き起こす可能性があります。そのため、できる限り、入力が「標準」入力に近いことを確認してください。可能。

いくつかのアイデア：

  • 前処理すべての画像と 修正 できます。このためには、 ゴムシート変換 を実行するために、いくつかの 基準マーカー が必要になります（ただし、あらゆる一般的なワープで実行されます）。

  • より簡単な代替策として、レシートのバウンディングボックスの回転を決定できます。次に、画像全体を回転させます（この境界ボックスの左上隅から、つまり領収書の境界ボックスに対して）。これは、見かけの直交性をsomewhatに戻すための良い最初のステップです。その後、再度OCRを実行します。それ以外の場合は、既に決定されたテキストボックスを回転できますが、常にレシート境界の左上隅の原点（または右上ですが、通常は境界上の点）を基準にして回転できます。

  • 一致するパターンが必要な場合は、かなり標準的な形状のbarcodeを思い出してください。レシートの例示的な画像（完全な直交配置など）を用意し、フィーチャマッチングを使用して、任意の画像からこの基本的な「グラウンドトゥルース」画像への変換を決定し、それに応じてワープできます。 ここ は、まさにそれをやりたかった人の例です。これは MATLABの例 でも同じことを行うので、（使用するものに応じて）これらの例を適応または借用する方法を見つけることができます。機能照合アルゴリズムが、一致するバーコード機能を比較的適切に検索することを期待しています。

  • 既に行っていることを続けることができますが、テキストボックスの回転に基づいて投影する代わりに、領収書境界ボックスに対して垂直に投影できます。これにより、「本質的な」位置合わせの感覚が向上します（つまり、OCRで検出されたテキストの位置合わせではなく、画像に関して）。これは、領収書の上部から下部に向かって下向きに走る架空のscanlineに似ています。各位置で、交差するものはすべて同じ行に属します。もちろん、これは「すべてのケース」をカバーするように小さな調整を行うようなものなので、これはまだ非常に堅牢なソリューションではありません。

3
Vector Zita