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

Поиск даты в случае хорошего и плохого распознавания

Данная глава описывает некоторые характерные приемы создания гибких описаний, которые можно использовать для поиска полей на изображениях низкого качества. На практике часто встречаются изображения с различными дефектами сканирования, вызванными некорректными настройками сканера. Например, изображение может быть слишком светлым или слишком темным, если при сканировании использовались неверные настройки яркости, и т.п. В результате часть информации на изображении может быть потеряна (засвечена), часть может быть покрыта так называемым «мусором», т.е. темными точками и штрихами.

В программе FlexiLayout Studio предусмотрен специальный элемент Date, который позволяет задавать условия поиска даты. Однако в ходе создания гибкого описания могут выявиться объективные причины, по которым использование этого элемента для поиска даты может оказаться недостаточным. Причиной для возникновения этой ситуации может стать несоответствие реальной даты ни одному из форматов, допустимых при описании элемента Date. В частности, при задании месяца в поле даты словом, программа FlexiLayout Studio допускает следующие языки: русский, английский, венгерский, голландский, греческий, датский, испанский, итальянский, латышский, литовский, немецкий, норвежский, польский, португальский, турецкий, финский, французский, чешский, шведский, эстонский. При обработке изображений документов, представленных на любом другом языке, дата неизбежно будет противоречить заданному формату, и не будет найдена при использовании элемента типа Date.

Другой причиной может стать наличие на изображении не удаляемых элементов формы, например, дата может быть подчеркнута (имеется в виду ситуация, когда между подчеркиванием и датой нет просвета), перечеркнута (например, вследствие сканирования) или вписана в знакоместа, с черными ограничителями (рамками, гребенкой). Невозможность поиска даты с помощью специализированного элемента Date может быть также связана с наличием мусора в области поиска, а также в случае, если дата вписана не печатными символами, а от руки.

Рассмотрим на примере проекта SearchOfDate.fsp (папка %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Date, как можно организовать поиск поля даты.

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

  • Страница 1 - формат даты можно описать с помощью элемента Date;
  • Страница 2 – дата содержит название месяца на французском языке;
  • Страница 3 – дата подчеркнута;
  • Страница 4 – в поле даты находится мусор;
  • Страница 5 – поле даты заполнено от руки.

Попробуем найти дату на всех изображениях, в том числе на тех, где формат даты отличается от формата, поддержанного элементом типа Date.

Все элементы, имеющие логическое отношение к полю даты объединяются в группу DateGroup. Вначале в ней располагается элемент для поиска заголовка поля даты. В нашем проекте - это элемент типа Static Text с именем DateHeader и единственным значением « Date: ».

Замечание. Задание условий для поиска всех элементов на вкладке Relations не составляет сложности и выходит за рамки рассмотрения, их можно посмотреть непосредственно в проекте.

Затем создаем элемент типа Date с именем DateField. С помощью этого элемента будет осуществлен поиск тех полей даты, для описания формата которых достаточно свойств элемента типа Date.

Как можно видеть в пакете проекта, с помощью элемента Date удается найти дату только на первой странице.

Для поиска полей даты на всех остальных страницах создается элемент типа Character String. В нашем проекте это элемент DateAsString. В качестве алфавита в нем задается все множество символов, которые предположительно могут встретиться на обрабатываемых изображениях.

Замечание. Если содержимое поля даты может быть структурировано (имеет конкретный формат, который по каким-либо причинам не совпадает ни с одним из форматов элемента Date), то вместо задания алфавита может быть целесообразным описать этот формат с помощью регулярного выражения. Однако, при этом надо быть уверенным в хорошем качестве обрабатываемых изображений, поскольку задание регулярного выражения предполагает точное соответствие искомого поля заданной структуре, в то время как задание алфавита может допускать наличие некоторого процента ошибок (задается в свойствах элемента), а потому является более гибким на случай, если полное отсутствие неточностей распознавания нельзя гарантировать. Если заранее известно, что формат даты предполагает написание месяца словом на языке, совпадающем с языком предраспознавания, заданным в свойствах гибкого описания, то может оказаться целесообразным разбить поле даты на три составляющие (число, месяц, год) и искать поле месяца отдельно с помощью элемента типа Static Text с указанием всех возможных значений (собственно, названий месяцев полных и/или сокращенных на данном языке). А поля день и год искать уже в виде строк (регулярных выражений) элементами типа Character String справа и слева от поля месяца.

Для оптимизации процедуры наложения гибкого описания (для ускорения процедуры наложения гибкого описания в случае, если формат даты совпал с одним из стандартизованных форматов элемента Date) в секции Advanced pre-search relations для элемента DateAsString записано следующее условие:

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

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

if not DateField.IsNull then Dontfind();
    

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

Как можно видеть в пакете проекта, с помощью элемента DateAsString удается найти дату на всех остальных страницах пакета, на которых дата не была найдена с помощью элемента типа Date.

Однако на странице 4 найденная строка лишь частично включает поле даты. Если посмотреть результаты предраспознавания для поля даты (для этого надо нажать кнопку Show Raw Objects на панели инструментов), то станет ясна причина такого частичного нахождения даты: дело в том, что в области поиска даты находятся не только текстовые объекты, а еще объекты других типов – в данном случае Picture (картинка) и Punctuation mark (знаки препинания). Такая ситуация характерна для изображений с низким качеством – не всегда текстовые объекты обнаруживаются в процессе предраспознавания.

Для того чтобы найти все объекты, составляющие содержимое поля даты, создан элемент типа Object Collection с именем DateAsObjectCollection. В свойствах элемента указываются все типы объектов, которые при предраспознавании были обнаружены в поле даты. Для оптимизации процедуры наложения гибкого описания в секции Advanced pre-search relations для элемента DateAsObjectCollection, также как и для элемента DateAsString записано следующее условие:

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

Замечание. Мы не можем добавить в свойства Advanced элемента DateAsObjectCollection условие if (DateAsString.IsNull == FALSE) then Dontfind(); поскольку, как мы выяснили в ходе рассмотрения данного примера, нельзя исключить ситуацию, при которой найденная строка может включать только часть даты.

На этом создание элементов, описывающих условия поиска поля даты можно считать законченным. В качестве Source element для блока Date в дереве проекта указана группа элементов SearchElements.DateGroup.AlternativeDateGroup, состоящая из элементов DateField, DateAsString и DateAsObjectCollection. Поскольку при описании свойств элементов DateAsString и DateAsObjectCollection был использован метод Dontfind(), реальный регион найденного блока будет соответствовать либо региону найденной гипотезы элемента Date, либо объединению регионов элемента DateAsObjectCollection с регионом элемента DateAsString. В последнем случае мы ожидаем, что регион элемента DateAsString будет частью региона элемента DateAsObjectCollection, так что результатом объединения будет регион элемента DateAsObjectCollection.

Замечание. В данном случае мы можем указать в качестве Source element группу элементов SearchElements.DateGroup.AlternativeDateGroup, поскольку ситуация достаточно простая. Регион группы состоит из объединения регионов найденных подэлементов. Метод Dontfind() позволяет не искать некоторые подэлементы. Таким образом, регион составного элемента SearchElements.DateGroup.AlternativeDateGroup будет совпадать с регионом нужного нам найденного подэлемента. В данном случае использование метода Dontfind() позволило нам не только оптимизировать процесс поиска блока (ускорить процедуру наложения гибкого описания), но и упростить описание блока.

В качестве альтернативы можно было бы использовать код, заданный в секции Expression.

Rect OutputRect;
let dateGroup = SearchElements.DateGroup.AlternativeDateGroup;
if (dateGroup.DateField.IsNull == FALSE) then
outputRect = dateGroup.DateField.Rect;
else
outputRect = dateGroup.DateAsObjectCollection.Rect;
OutputRegion = outputRect;
    

Использование Expression предоставляет дополнительные возможности. Например, мы могли бы проверить, что регион элемента DateAsString действительно является частью региона элемента DateAsObjectCollection.

Замечание. Поиск поля даты при помощи элемента Character String без ограничения формата строки или при помощи элемента типа Object Collection, как в данном примере, дает хороший результат в случае, если удается четко ограничить область поиска данного поля. Если же в области поиска присутствует несколько строчек, то для поиска поля необходимо наложить ограничения на формат строки – например, задав регулярное выражение или более строгий алфавит. Иначе в качестве результата может быть выбрана не та гипотеза, которую мы хотели найти. В случае использования элемента типа Character String можно воспользоваться ограничениями на длину строки, число концов слов и длину пробела внутри строки для отсеивания неподходящих гипотез. В случае с элементом типа Object Collection в гипотезу будут включены все объекты изображения, попавшие в область поиска и удовлетворяющие ограничениям на размеры отдельного объекта.

01.12.2020 7:04:05


Please leave your feedback about this article