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

Поиск однострочных полей фиксированного или произвольного формата при разном качестве распознавания

Для нахождения однострочных полей в программе FlexiLayout Studio предусмотрен элемент типа Character String. Если искомое поле имеет фиксированный формат, его можно описать в свойствах соответствующего элемента на вкладке Character String в поле Regular expression. Однако использование регулярного выражения для поиска элемента подразумевает печатное заполнение и хорошее качество соответствующего фрагмента изображения, поскольку описание с помощью регулярного выражения не допускает наличия в поле ошибок, которые могут возникнуть, например, при попадании в область поиска мусора или при наличии белесых участков (плохом качестве печати). Наличие каких-либо ошибок в поле, описанном с помощью регулярного выражения, приведет к тому, что элемент не будет найден. Также, нельзя использовать регулярные выражения при заполнении поля от руки, даже если структура поля поддается описанию. Тем не менее, найти такое поле можно.

Рассмотрим на примере проекта StructuredStrings.fsp (папка %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Structured strings), как можно организовать поиск однострочного поля “Номер счета”, имеющего одинаковый формат на всех страницах.

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

  • Страница 1 и 2 - поле “Номер счета” заполнено печатным способом, качество изображения хорошее;
  • Страница 3 – поле “Номер счета” заполнено печатным способом, но в поле имеется мусор;
  • Страница 4 – качество изображения хорошее, но поле “Номер счета” заполнено от руки.

Поле “Номер счета” мы будем искать относительно заголовка. Поэтому вначале необходимо создать элемент, описывающий условия поиска заголовка. Для поиска заголовка был создан элемент типа Static Text с именем InvoiceNumberHeader и значением “InvoiceN:”.

Поле “Номер счета” – однострочное. Поэтому для его поиска мы вначале создали элемент типа Character String с именем NumAsRegularExpression. Как можно видеть при просмотре страниц в пакете, формат поля “Номер счета” можно описать с помощью следующего регулярного выражения:

NNNN"-"NN"-"[A-Z]"/"NN
    

или, что то же самое:

[0-9]{4}"-"[0-9]{2}"-"[A-Z]"/" [0-9]{2}
    

Что означает, что номер состоит из последовательности: “четыре цифры – две цифры – одна прописная буква (на латинице)/две цифры”

Как можно видеть в пакете проекта, после запуска процедуры наложения гибкого описания по команде Match для страниц 3 и 4 были сформированы нулевые гипотезы для элемента NumAsRegularExpression, т.е. элемент оказался не найден. На странице 3 наличие мусора привело к несоответствию данных поля структуре, описанной регулярным выражением. Если открыть страницу 3 и нажать кнопку “ L ” (“ Show Recognized Lines ”) на панели инструментов, то результат предраспознавания номера счета на этой странице выглядит так “10&0-20-A/04”. На 4 странице номер счета заполнен от руки. При просмотре результата предраспознавания (Z.OOO-41-C/03) видно, что он также не соответствует описанному формату.

Для преодоления данной проблемы предлагается следующее решение. Создаем еще один элемент типа Character String с именем NumAsAlphabet. Задаем для него те же условия поиска, что и для ранее созданного элемента NumAsRegularExpression. И объединяем оба эти элемента в группу InvoiceNumber. Но в качестве описания элемента NumAsAlphabet задаем уже не регулярное выражение, а список всех допустимых символов.

В секции Advanced pre-search relations необходимо записать следующий код:

if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
    

Это означает, что попытка поиска номера счета в виде строки нефиксированного формата, описанной элементом NumAsAlphabet, будет осуществляться только в том случае, если его не удалось найти с помощью элемента NumAsRegularExpression, описывающего строку фиксированного формата.

Замечание. Для описания условий поиска элемента NumAsAlphabet можно воспользоваться методом drag&drop для копирования их из секции Relations элемента NumAsRegularExpression в одноименную секцию данного элемента. В качестве альтернативы можно записать в секции Advanced pre-search relations следующий код:

if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
else RestrictSearchArea (NumAsRegularExpression.Rect);
    

Данный код означает, что попытка поиска элемента NumAsAlphabet будет осуществляться только в том случае, если структура номера счета не соответствует заданному формату, т.е. не удалось найти элемент NumAsRegularExpression. Причем поиск элемента NumAsAlphabet будет осуществляться именно в той области, в которой не удалось найти элемент NumAsRegularExpression.

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

В дереве проекта мы создали текстовый блок с именем InvoiceNum. И в качестве Source element для него подключили группу SearchElements.InvoiceNumber. На этом создание гибкого описания для поиска поля “Номер счета” можно считать законченным.

Замечание. Если по какой-либо причине описанный выше прием окажется недостаточным для нахождения поля (независимо от того фиксированный у него формат или произвольный), то в группе можно создать еще один элемент (элемент типа Object Collection). В данном проекте – это элемент типа Object Collection с именем NumAsObjectCollection, который при том качестве изображений, которые присутствуют в нашем проекте, по сути, не нужен, приводится здесь только в качестве примера, и потому он исключен из рассмотрения (для него выполнена команда Disable). Включение дополнительного элемента типа Object Collection может понадобиться, когда результаты предраспознавания на разных страницах практически непредсказуемы, но область поиска удается задать достаточно точно, не боясь, что в гипотезу попадет ненужная информация.

Может возникнуть вопрос: зачем нужно создавать элемент с регулярным выражением, если все равно в некоторых случаях поле ищется без его использования? Дело в том, что использование регулярного выражения повышает надежность поиска. Если удалось найти подобный элемент, то можно быть уверенным, что нашлась именно та строка, которую мы искали. Эту информацию можно использовать в дальнейшем при поиске других элементов, опираясь на надежно найденный элемент и используя его в отношениях с другими элементами. При ослаблении условий на формат искомой строки снижается уверенность в том, что найденный элемент – тот, что нужно.

Это может получиться, например, при наличии большого количества мусора или белесых участков на рассматриваемом фрагменте изображения. В этом случае, при использовании для поиска элемента типа Character String с заданным алфавитом плохое качество изображения может привести к превышению допустимого процента ошибок (параметр Percentage of non-alphabet characters). В результате либо элемент совсем не будет найден, либо он будет найден, но в него попадет только часть данных искомого поля. Пример такой ситуации приведен на рисунке ниже.

11/10/2020 12:08:08 PM


Please leave your feedback about this article