Russian (Русский) - Change language

Оптимизация поиска составного элемента

Если все гипотезы цепочки элементов, входящих в составной элемент (Group), имеют качество 1, то остальные гипотезы этих элементов не рассматриваются.

Замечание. Это делается в целях оптимизации работы гибкого описания, с тем, чтобы ускорить процедуру его наложения и избежать чрезмерного “разрастания” дерева гипотез. Хотя не всегда оптимальная с точки зрения программы, гипотеза соответствует искомому объекту изображения. Это может быть вызвано тем, что в ходе настройки соответствующих элементов были описаны свойства и условия поиска, которых оказалось недостаточно для однозначного определения местоположения искомого объекта. Поэтому, если такая ситуация произошла, необходимо в первую очередь проанализировать сделанные настройки.

Проиллюстрируем это на примере проекта GO.fsp (папка %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1). Будем искать поле “Номер счета”.

В проекте находятся 2 страницы:

  • Страница 1 – качество изображения хорошее;
  • Страница 2 – в заголовке искомого поля на изображении присутствует мусор.

Мы создали группу InvoiceGroup, в которой размещаются элементы для поиска заголовка поля (элемент типа Static Text с именем InvoiceHeader и значением “INVOICE”), и элемент типа Character String с именем InvoiceNumber - для поиска собственно поля “Номер счета”. На вкладке Relations элемента InvoiceNumber мы задали условия поиска поля данных относительно заголовка.

Замечание. Регистр написания значения заголовка в секции Search text может быть любой.

Обратим внимание, что строка “Invoice”, заданная в качестве значения для элемента InvoiceHeader, на тестовых изображениях присутствует трижды: в виде заголовка к полю “Номер счета”, в виде подстроки в заголовке “Invoice date:” и внизу счета, в виде подстроки в условиях платежа “Current invoice is…”. На основании чего можно предположить, что и сформированных гипотез при наложении гибкого описания также окажется три. Посмотрим, что получится при наложении гибкого описания на примере первого тестового изображения в пакете.

После запуска процедуры наложения гибкого описания по команде Match увидим, что дерево гипотез внутри группы InvoiceGroup имеет всего одну завершенную цепочку, а не три, как мы предположили вначале. Причем завершенная цепочка гипотез вовсе не соответствует искомому заголовку.

Если посмотреть на свойства гипотез каждого элемента в сформированной цепочке, то можно увидеть что качество каждой гипотезы (Chain quality) равно 1. Т.е. в данном случае сработал принцип оптимизации - при нахождении идеальной с точки зрения качества (т.е. с качеством 1) цепочки генерация гипотез прекращается.

Замечание. Чтобы увидеть дерево гипотез группы, необходимо дважды щелкнуть мышью на имени составного элемента в дереве гипотез проекта, либо нажать Enter, либо выбрать пункт Show Details контекстного меню.

Принцип, по которому при формировании гипотезы предпочтение отдается тому или иному объекту изображения (несмотря на одинаковое качество), заложен внутри алгоритма программы.

Поскольку результаты наложения гибкого описания нас не устраивают, проанализируем, почему так получилось, и как можно данную ситуацию исправить.

Во-первых, мы не задали никаких условий, где надо искать элемент InvoiceHeader. Во-вторых, при описании элемента InvoiceNumber мы задали, что числовая строка может быть любой длины (поскольку мы не можем предсказать, какой длины будет строка номера). Также мы задали, что искать ее надо правее элемента заголовка, примерно на одном с ним уровне (с небольшим запасом по высоте). Как можно видеть, для всех трех слов “invoice” эти условия соблюдаются. Поэтому после неверного нахождения заголовка автоматически последовало ошибочное обнаружение поля “Номер счета”. Т.е. необходимо каким-либо способом наложить дополнительные, ограничительные условия, с тем, чтобы конкретизировать программе задачу поиска, чтобы лучшей в итоге оказалась правильная гипотеза, а все прочие оказались бы оштрафованы. Т.е., чтобы гибкое описание оказалось оптимальным не только по быстродействию.

Если рассматривать нашу форму, как формализованную, т.е., если предположить, что взаимное положение полей на всех изображениях, которые мы будем обрабатывать с помощью данного гибкого описания, будет одинаково, то самый простой способ – это “сообщить” программе, что нас интересует строка “Invoice”, расположенная ближе всех остальных к правому краю листа. Т.е. записать в секции Advanced pre-search relations элемента InvoiceHeader код: Nearest: PageRight; (попробуйте раскомментировать эту строчку в секции Advanced pre-search relations и посмотрите, как изменится поведение гибкого описания). Мы можем так поступить, поскольку заголовок искомого поля “Номер счета” является единственным ближайшим элементом к правому краю страницы. Если бы это было не так, или взаимное расположение полей на разных страницах менялось (т.е. форма не являлась формализованной), функция Nearest не помогла бы решить нашу задачу.

Для иллюстрации того, как можно по-другому решить нашу задачу, в том числе, если форма не является формализованной, мы создали проект GO.fsp (папка GO\2).

Как видно на всех изображениях, между числовой строкой и словом “invoice” расстояние будет наименьшим в искомом поле “Номер счета”. Соблюдение этой закономерности на всех страницах дает нам возможность повлиять на качество сформированных гипотез, если мы зададим в секции Advanced post-search relations элемента InvoiceNumber следующий код:

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

Он означает, что, если оба элемента найдены, для гипотезы элемента InvoiceNumber вычисляется разница между левой границей прямоугольника данного элемента и правой границей прямоугольника элемента InvoiceHeader (т.е. расстояние между найденными элементами). И проверяется вхождение этой разницы в нечеткий интервал {0, 0, 0, 10000}*dt. Такая запись нечеткого интервала означает прямую линейную зависимость между штрафом, налагаемым на качество гипотезы, и расстоянием между элементами. Т.е. чем дальше элементы находятся друг от друга, тем выше штрафующий коэффициент (функция FuzzyQuality возвращает качество, на которое домножается post-search качество гипотезы – его можно увидеть в окне свойств гипотезы). Значение правой границы интервала (10000dt) было подобрано опытным путем. При подборе следует учитывать данные о расстоянии между соответствующими объектами на тестовых изображениях.

Как следует из схемы, приведенной ниже, при заданных нами границах диапазона, максимальный штраф (1) будет соответствовать расстоянию 10000dt. Расстоянию в 1000dt будет соответствовать штраф 0,1. Расстоянию в 100dt – 0,01 и т.д.

Т.е для реальных расстояний порядка 100-300 dot, наблюдаемых на наших изображениях, вычисленный штрафующий коэффициент будет 0.99-0.97.

Замечание. Более подробная информация о функциях Nearest и FuzzyQuality приведена в разделе Использование функций Nearest и FuzzyQuality для поиска элементов.

На изображениях, которые находятся в нашем пакете, максимальному штрафу подверглась гипотеза, соответствующая ошибочно найденному полю “Номер счета” со значением 2005, а минимальному – гипотеза, соответствующая искомому полю. Поскольку наложение штрафа привело к тому, что Post-search quality всех гипотез элемента InvoiceNumber стало отличным от 1, при поиске лучшей цепочки теперь рассматриваются все гипотезы обоих элементов составного элемента InvoiceGroup.

Обратите внимание на то, что поле “Номер счета” было правильно найдено и на странице 2, несмотря на то, что в заголовке “INVOICE” присутствует мусор, приведший к появлению ошибки в этом заголовке, и, следовательно, к дополнительному штрафованию соответствующей гипотезы.

11/10/2020 12:08:08 PM


Please leave your feedback about this article