グループ要素の検索の最適化

FlexiLayout Studio で グループ要素 の検索を最適化します。品質 1 のチェーンでは仮説生成が停止するため、正しく検出するには FuzzyQuality ペナルティを適用します。

グループ要素 内の要素チェーンについて、すべての仮説の品質値が 1 の場合、それらの要素のほかの仮説は解析されません。

これは、FlexiLayout を最適化し、マッチング処理を高速化するとともに、仮説ツリーの不要な「分岐」を避けるために行われます。ただし、FlexiLayout Studio にとって最適な仮説が、画像上で探しているオブジェクトに必ずしも対応するとは限りません。

これは、要素の検索条件が十分に厳しくない場合に起こり得ます。このような状況が発生した場合は、まず要素検索に設定したパラメーターを解析します。

​

GO.fsp sample プロジェクト

field「請求書番号」を見つけることを目的としたプロジェクト GO.fsp (フォルダー %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1) を見てみましょう。

このプロジェクトには 2 つのページがあります。

• ページ 1 – 画質は良好です。
• ページ 2 – 検索対象の field 名にノイズがあります。

このプロジェクトには InvoiceGroup というグループがあり、その中に field 名を検索するための要素が含まれています。これは、値が「INVOICE」の InvoiceHeader という名前の Static Text 要素です。

field「請求書番号」自体を検索するために、このプロジェクトでは InvoiceNumber という名前の Character String 要素を使用します。名前に対する field の検索条件は、InvoiceNumber 要素の Relations セクションで指定されています。

名前の Search text セクションでは、大文字と小文字は関係ありません。

​

仮説の生成が品質 1 のチェーンで停止する理由

InvoiceHeader 要素の値として指定された文字列 “Invoice” は、画像内に 3 回現れている点に注意してください。1 つは “請求書番号” field 名として、1 つは “Invoice date” という名前の一部として、もう 1 つは請求書の下部にある支払い条件 “Current invoice is…” の一部として現れています。

したがって、マッチング手順の後には 3 つの仮説が生成されると予想できます。

Match コマンドを選択して FlexiLayout のマッチング手順を実行すると、グループ要素 InvoiceGroup の仮説ツリーには、予想された 3 つではなく完全なチェーンが 1 つしかなく、その 1 つのチェーンは検出されるべき名前に対応していないことがわかります。

生成されたチェーン内の各要素のプロパティを見ると、各仮説の チェーンの品質 が 1 であることがわかります。これによって最適化が行われました。つまり、FlexiLayout Studio は品質の観点で理想的なチェーン (つまり、品質が 1 のチェーン) を検出すると、仮説の生成を停止します。

グループの仮説ツリーを表示するには、仮説ツリー内の グループ要素 の名前をダブルクリックするか、Enter キーを押すか、ショートカットメニューから Show Details を選択します。

FlexiLayout Studio のアルゴリズムによって、仮説生成中に画像内のどのオブジェクトがほかより優先されるかが決まります。

FlexiLayout のマッチング結果は満足のいくものではないため、問題の原因を解析し、どう解決できるかを判断する必要があります。

まず、InvoiceHeader 要素の検索領域が制限されていません。次に、InvoiceNumber 要素の記述では、数字列の長さを任意にできるよう指定されています (請求書番号として想定される長さが不明なためです) 。また、その文字列は名前の右側にあり、おおよそ同じ高さの位置で探すよう指定されています。

ご覧のとおり、“Invoice” という単語の 3 つの出現箇所はいずれもこれらの条件に一致します。そのため、名前の誤検出によって “請求書番号” field も自動的に誤検出されました。最終的に正しい仮説が最良のものとなるよう、また FlexiLayout がマッチング速度の点だけでなく全体として最適になるように、いくつかの制約を追加する必要があります。

​

Nearest を使って名前をページの右端に関連付ける

プロジェクト内のすべてのページで field の配置が同じだと想定できる場合、最も簡単な方法は、目的の文字列 “Invoice” がページの右端に最も近い要素であることを FlexiLayout Studio に「伝える」ことです。そのためには、InvoiceHeader 要素の Advanced pre-search relations セクションに次のコードを記述します: Nearest: PageRight;.

これが機能するのは、探している field 名 “請求書番号” が、ページの右端に最も近い唯一の要素だからです。そうでなかったり、文書が定型化されていなかったりする場合は、Nearest function ではこの問題を解決できません。

​

FuzzyQuality を使用して離れた数字の仮説にペナルティを与える

半構造化文書の場合を含め、このtaskを実行する別の方法を GO.fsp project (フォルダー GO\2) に示しています。

画像を見ると、数字の文字列と単語 “invoice” との距離は、探しているfield “請求書番号” で最も小さいことがわかります。

これはすべてのページに当てはまるため、InvoiceNumber 要素の Advanced post-search relations セクションに次のコードを入力して、生成された仮説の品質値に影響を与えることができます:

if (not InvoiceHeader.IsNull) and (not IsNull) then
{ FuzzyQuality: Rect.Left - InvoiceHeader.Rect.Right, {0, 0, 0, 10000}*dt; }

これは、両方の要素が検出された場合、要素 InvoiceNumber の仮説について要素間の距離が計算され、その距離が区間 {0, 0, 0, 10000}*dt に含まれるかどうかを FlexiLayout Studio が確認することを意味します。

この区間の定義は、仮説のqualityと要素間の距離が線形に依存することを示しています。つまり、距離が長いほどペナルティは大きくなります (関数 FuzzyQuality は仮説のpost-search qualityを返します。これは仮説の Properties ウィンドウで確認できます)。

区間の右境界の値 (10000dt) は、実験によって決定されました。この値を選ぶ際は、テスト画像上の対応するobject間の距離を考慮する必要があります。

次の図に示すように、指定した区間のプロパティでは、最大ペナルティ (1) は距離 10000dt に対応します。したがって、距離が 1000dt の場合のペナルティは 0.1、100dt の場合は 0.01 となり、以下同様です。

したがって、画像で確認できる約 100～300 ドットの実際の距離では、ペナルティ係数は 0.99～0.97 になります。

これらの関数の使用方法の詳細については、Nearest と FuzzyQuality を使用した要素の検索 を参照してください。

このbatchの画像では、不要なfield「請求書番号」で値が「2005」の仮説には最大のペナルティが与えられた一方、探しているfieldに対応する仮説には最小のペナルティが与えられました。

ペナルティが加えられたことで、すべての仮説の Post-search quality が 1 ではなくなったため、グループ要素 InvoiceGroup の両方の要素について、すべての仮説が解析されるようになります。

なお、field「請求書番号」は、名前「Invoice」に非常に多くのノイズがあり、その結果認識エラーが発生して仮説に追加のペナルティが課されたページ 2 でも、正しく検出されました。