メインコンテンツへスキップ
グループ要素 (Group) 内の要素チェーンについて、すべての仮説の品質値が 1 の場合、それらの要素のほかの仮説は解析されません。
これは、FlexiLayout を最適化し、マッチング処理を高速化するとともに、仮説ツリーの不要な「分岐」を避けるために行われます。ただし、プログラムにとって最適な仮説が、画像上で探しているオブジェクトに必ずしも対応するとは限りません。これは、要素の検索条件が十分に厳しくない場合に起こり得ます。そのため、このような状況が発生した場合は、まず要素検索に設定したパラメーターを解析する必要があります。
field「請求書番号」を検索するプロジェクト GO.fsp (フォルダー %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1) を考えてみましょう。 このプロジェクトには 2 ページあります。
  • ページ 1 – 画質は良好です。
  • ページ 2 – 探している field 名にノイズがあります。
field 名を検索するための要素を含むグループ InvoiceGroup を作成しました。これは Static Text 型の要素で、名前は InvoiceHeader、値は “INVOICE” です。field「請求書番号」自体を検索するために、Character String 型の要素 InvoiceNumber も作成しました。要素 InvoiceNumber の Relations セクションでは、名前に対する日付 field 検索の検索条件を指定しました。
Search text セクションでは、名前の大文字と小文字は区別されません。
要素 InvoiceHeader の値として指定した文字列 “Invoice” は、画像内に 3 回現れることに注意してください。つまり、「請求書番号」field 名として 1 回、「Invoice date」という名前の一部として 1 回、さらに請求書の下部にある支払い条件 “Current invoice is…” の一部として 1 回です。したがって、マッチング処理の後には 3 つの仮説があると予測できます。 Match コマンドを選択して FlexiLayout のマッチング処理を実行すると、グループ InvoiceGroup の仮説ツリーには、予想していた 3 つではなく、完全なチェーンが 1 つしかないことがわかります。また、残っているその完全な仮説チェーンは、検出しようとしている名前に対応していません。 生成されたチェーン内の各要素のプロパティを見ると、各仮説の Chain quality が 1 であることがわかります。これが最適化を引き起こしました。つまり、プログラムは品質の点で理想的なチェーン (すなわち品質が 1 のチェーン) を検出すると、仮説の生成を停止します。
グループの仮説ツリーを表示するには、仮説ツリー内の グループ要素 名をダブルクリックするか、Enter キーを押すか、shortcut menu から Show Details を選択します。
仮説生成の段階で、画像内のあるオブジェクトがほかのものより優先される理由は、プログラムのアルゴリズムによって決まります。 FlexiLayout のマッチング結果が満足のいくものではないため、問題の原因を解析し、どのように解決できるかを判断する必要があります。 まず、要素 InvoiceHeader の検索領域を制限していませんでした。次に、要素 InvoiceNumber を記述する際に、数字の文字列の長さを任意に指定しました (請求書番号の長さとしてどの程度の値があり得るかわからないためです) 。また、その文字列は名前の右側で、ほぼ同じ水平位置にあるものを検索するよう指定しました。ご覧のとおり、3 つの “Invoice” はすべてこれらの条件に一致します。そのため、名前の誤検出によって、「請求書番号」field の誤検出も自動的に引き起こされました。最終的に正しい仮説が最良になるように、そして FlexiLayout がマッチング速度の点だけでなく全体としても最適になるように、いくつかの制限条件を追加する必要があります。 プロジェクトのすべてのページでfieldの配置が同一であると仮定すると、最も簡単な方法は、ページの右端に最も近い要素である文字列「Invoice」が必要であることをプログラムに「伝える」ことです。そこで、要素 InvoiceHeader の Advanced pre-search relations セクションに次のコードを記述します: Nearest: PageRight;。これが可能なのは、探しているfield「請求書番号」の名前が、ページの右端に最も近い 唯一の 要素 だからです。そうでなかった場合や、documentが定型化されていない場合は、関数 Nearest ではこの問題を解決できません。 半構造化文書の場合を含め、このtaskを実行する別の方法を示すために、project GO.fsp (フォルダー GO\2) を作成しました。 画像を見ると、数字の文字列と単語「invoice」との距離は、探しているfield「請求書番号」で最も小さいことがわかります。これはすべてのページに当てはまるため、要素 InvoiceNumber の Advanced post-search relations セクションに次のコードを入力して、生成された仮説のquality値に影響を与えることができます。 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 に含まれるかどうかをプログラムが確認することを意味します。この区間の定義は、仮説のqualityと要素間の距離が線形に依存することを示しています。つまり、距離が長いほどペナルティは大きくなります (関数 FuzzyQuality は仮説のpost-search qualityを復元します。これは仮説の Properties ウィンドウで確認できます) 。区間の右境界の値 (10000dt) は、実験によって決定されました。この値を選ぶ際は、テスト画像上の対応するobject間の距離を考慮する必要があります。 下の図に示すように、指定した区間のプロパティでは、最大ペナルティ (1) は距離 10000dt に対応します。したがって、距離が 1000dt の場合のペナルティは 0.1、100dt の場合は 0.01 となります。 したがって、画像で確認できる約 100～300 dot の実際の距離では、ペナルティ係数は 0.99～0.97 になります。
これらの関数の使用方法の詳細については、Using Nearest and FuzzyQuality to look for elements を参照してください。
このbatchの画像では、不要なfield「請求書番号」で値が「2005」の仮説には最大のペナルティが与えられた一方、探しているfieldに対応する仮説には最小のペナルティが与えられました。ペナルティが加えられたことで、すべての仮説の Post-search quality が 1 ではなくなったため、グループ要素 InvoiceGroup の両方の要素について、すべての仮説が解析されるようになります。 なお、field「請求書番号」は、名前「Invoice」に非常に多くのノイズがあり、その結果認識エラーが発生して仮説に追加のペナルティが課されたページ 2 でも、正しく検出されました。