オブジェクトの検索には、Group 要素を使用するのが最も効率的です。要素をグループ化すると、各要素に対する仮説の数が減り、その結果、FlexiLayout 全体の仮説の検索が高速になるためです。さらに、要素のグループ化がドキュメントの論理を反映していれば、FlexiLayout の構造の最適化に役立ち、より明確になります。
複数の要素を 1 つのグループ要素にまとめると、プログラムはその要素セット全体を、独自の仮説 (グループ内の各要素の個別の仮説で構成される) を持つ 1 つのまとまりとして扱えるようになります。仮説とその要素の解析は グループ要素 内で行われ、その後ほかの要素を検索する際には、ユーザーが指定した数 (既定では 1 個) の最良の仮説だけが使用されます。
要素ツリー全体を 1 つのグループ要素と見なすことができ、その最良の仮説が FlexiLayout のマッチング結果になります。
GroupSample.fsp プロジェクト (フォルダー %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Group\Project1) を使って、グループ要素の使用方法を見ていきましょう。ここでは、請求書番号、請求日、請求金額のフィールドを検出したい画像があります。
画像からわかるように (これは通常、すべての財務書類にも当てはまります) 、ドキュメント番号と日付は隣り合うフィールドです。別のドキュメントでフィールドの配置が異なっていても、これらはやはり互いに近い位置にあります。さらに、これらは特定の銀行情報を表し、論理的なブロックを構成しているため、ドキュメントの論理上も関連しています。FlexiLayout の構造をより明確にするため、これらを InvoiceRequisiteGroup という名前のグループ要素にまとめます。
要素をグループ化する前に、特別な識別要素を作成しました。 (識別要素については、「ABBYY FlexiCapture での FlexiLayout の識別と処理」のセクションで詳しく説明されています。) この要素は、グループ要素 の有無によって仮説ツリーがどのように「枝分かれ」するかを示すためだけに作成したものです。ここでは、識別要素を除くツリー内のすべての要素は省略可能であり、それらのヌル仮説の既定の品質は 0.97 であると仮定します。
ここでは要素の設定については説明しません。詳細はプロジェクト内で直接確認できます。
仮説ツリーは 1 本のチェーンだけで構成されています。Group の品質は、Group 内で最良のチェーンの品質と一致します。
InvoiceRequisiteGroup をダブルクリックして Properties ダイアログを開くと、その サブ要素 に対してどのような仮説が生成されたか、Group 内でどのチェーンが最良と判断されたか、またその理由を確認できます。
InvoiceNumHeader 要素には 3 つの仮説があることがわかります。これは、検出された “invoice” 文字列の数と一致しています。目的の仮説の品質が低い (約 0.99) のは、その画像領域にノイズがあり、プログラムが “INVOICE” ではなく “INVOIC” としか認識できなかったためです。一方、他の 2 つの仮説の品質は最大です (チェーンの品質 = 1) 。
InvoiceNum 要素の作成時に、請求書番号は桁数を問わず、名前の右側を検索するよう指定しました。この画像では、この条件が 3 つすべてのケースで満たされていたため、プログラムは “Invoice number” field 名の各仮説について、仮説チェーンの作成を続行できました。ここで注目すべきなのは、InvoiceNum 要素の各仮説の Pre-search quality が 1 であるにもかかわらず、正しいと考えられるチェーンが依然として最も低いという点です。これは、チェーンの品質が、そのチェーンを構成するすべての仮説の品質を乗算して評価されるためです。必須の名前については、この品質は約 0.99 です。Group に他の要素がなければ、この段階での最終選択は誤っていたでしょう。
どの要素にも Post-search relations を指定していないため、各要素の Post-search quality は = 1 であり、任意の仮説の品質は Pre-search quality で判断できます。
最良の仮説の検索は Group 内で行われます。すべてのチェーンの品質が解析され、比較されます。Group の品質は、Group 内で最良のチェーンの品質によって決まります。
前述のとおり、InvoiceDateHeader 要素のプロパティでは、請求書番号の行の下を検索するよう指定しました。しかし、最良の品質を持つチェーン (チェーンの品質 = 1) ではどれも、日付 field 名の仮説は得られませんでした。そのため、これらのチェーンでは InvoiceDateHeader 要素に対してヌル仮説が生成されました。ヌル仮説のデフォルト品質を変更していないため、対応するチェーンの最終的なチェーンの品質は 0.97 に低下しました。一方、最も品質の低いチェーンでは、日付 field 名に対応する要素が見つかりました。その仮説の品質は約 0.993 です。これが 1 未満なのは、名前の領域の画像にノイズがあるためではなく、認識エラーが発生し、その結果、認識されたテキストと InvoiceDateHeader 要素のプロパティで指定された値との一致が不完全になったためです。その結果、見つかった仮説には減点が適用され、最終的な品質は約 0.98 になりました (0.99 と 0.993 を乗算した結果) 。それでも、この仮説の最終品質は他のもの (0.97) より高いため、この段階ではこのチェーンが最良です。
日付 field を検出するために、グループ要素 DateGroup を作成しました。これは、一方の要素が見つかった場合、もう一方の要素の少なくとも 1 つは見つからないよう指定するものです (Dontfind function を使用) 。ドキュメントの layout 上の特徴と、InvoiceDateAsString 要素に指定したプロパティ (そのアルファベットは数字を許可する) により、プログラムはすべてのチェーンについて日付 field を見つけることができましたが、3 つの仮説のうち実際に正しいのは 1 つだけです。
各 Group では、一方の要素が見つかり、もう一方が見つからないため、各 DateGroup group におけるチェーンの最終品質は 0.97 です (1 にヌル仮説のデフォルト品質である 0.97 を乗算) 。この例では、DateGroup チェーンの最終品質は、InvoiceDateHeader 要素の検出時点での仮説間の「バランス」には影響しません。つまり、各チェーンの品質は単純にさらに 0.97 倍されるだけです。
最後に、プログラムはグループ要素 InvoiceRequisiteGroup に対して 1 つの仮説を生成しました。これは Group 内の最良のチェーンに対応します。その品質は約 0.953 です。つまり、初期品質は低かったにもかかわらず、この “group approach” によって正しい仮説が選ばれました。
FlexiLayout でグループ要素を使用しない場合に仮説ツリーがどのようになるかを示すため、GroupSample.fsp プロジェクト (Group\Project2 フォルダー) を作成しました。ツリーは下図のとおりです。図からわかるように、FormID 要素が検出されると、InvoiceNumHeader 要素に対して複数の仮説が生成されるため、仮説ツリーは分岐します。その結果、プログラムは各チェーンの品質を比較するために、その都度、先頭の要素から末尾の要素までたどる必要があります。さらに、この例より複雑なレイアウトのドキュメントでは、グループ要素のない FlexiLayout は分岐が多すぎる仮説ツリーを生成するため、FlexiLayout のマッチングはいっそう難しくなります。
探している要素をすべて 1 つのルートグループに配置することは推奨されません。これは、要素数が 10 未満の非常に単純な FlexiLayout にのみ適していますが、実際のタスクでそのようなケースはごくまれです。ルート Group 内の要素数が増えると、仮説の数は急激に増加し、10,000 という上限に達するか、仮説ツリーに割り当てられたメモリを使い切るまで増え続けます。どちらの場合でも、FlexiLayout のマッチングに失敗する可能性があります。
グループ化されていない仮説ツリーは分岐が多すぎるため、見た目で解析するのが困難です。
さらに、最終的なチェーンの品質は、そのチェーン内のすべての仮説の品質を掛け合わせて計算されるため、分岐が多すぎるツリーでは計算量が大幅に増える可能性があり、その結果、FlexiLayout のマッチングが遅くなります。 