Как стать автором
Обновить
0
Content AI
Решения для интеллектуальной обработки информации

ABBYY FlexiCapture Engine 9.0: как встроить технологию DataCapture в приложение (взгляд программиста)

Время на прочтение7 мин
Количество просмотров6.6K
Не так давно мои коллеги рассказывали читателям Хабра о новой версии продукта для разработчиков ABBYY FlexiCapture Engine 9.0, который позволяет нашим пользователям встраивать технологию извлечения данных из изображений в свои программные решения.

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

Начнём с базового сценария извлечения данных из изображений с использованием FlexiCapture Engine 9.0 (такой сценарий хорошо подходит для простого настольного приложения), а затем обсудим, что и как в этом сценарии можно менять, чтобы приспособить его к требованиям разрабатываемого приложения.
В рекламных материалах это выглядит так:



В коде это выглядит так (читайте комментарии):
 [C#]
// Загрузим FCEngine в текущий процесс
IEngineLoader engineLoader = new FCEngine.InprocLoader();
IEngine engine = engineLoader.Load( serialNumber, "" );

// Создадим экземпляр процессора и сконфигурируем его одним или более определениями документов
IFlexiCaptureProcessor processor = engine.CreateFlexiCaptureProcessor();
processor.AddDocumentDefinitionFile( sampleFolder + "Invoice_eng.fcdot" );

// Добавим файлы изображений во внутреннюю очередь на обработку
processor.AddImageFile( sampleFolder + "Invoices_1.tif" );
processor.AddImageFile( sampleFolder + "Invoices_2.tif" );

// Запустим обработку и получим первый (и в нашем случае единственный) результирующий документ
IDocument document = processor.RecognizeNextDocument();
assert( document != null ); // Не было ошибок обработки
assert( document.DocumentDefinition != null ); // Тип документа пределён и данные извлечены
assert( document.Pages.Count == 2 ); // Оба изображения вошли в этот документ

// Возьмём извлечённые данные и используем их по назначению
string invoiceNumber = documents.Sections[0].Fields[0].Value.AsString; // Для простоты доступ по индексам
...
Теперь подробнее опишем отдельные шаги этого сценария, примерно соответствующие откомментированным кускам в коде:

Загрузка FlexiCapture Engine


Загрузка объекта Engine-а соответствует загрузке и инициализации исполняемых модулей и выполняется, как правило, один раз при старте или при первом использовании.

Существует несколько вариантов загрузки. Можно грузить Engine непосредственно в основной процесс, как в приведённом примере, что удобно для простых настольных приложений. Можно также для повышения надёжности грузить Engine в отдельный рабочий процесс, что рекомендуется для серверных решений. При загрузке в отдельный процесс есть возможность управлять приоритетом и временем жизни этого процесса. Можно также создать пул из рабочих процессов, в котором потокобезопасные экземпляры Engine-а работают параллельно и полностью независимо друг от друга и периодически recycle-ятся. (В состав примеров включена готовая реализация такого пула.)

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

Создание и настройка процессора


FlexiCaptureProcessor – это легковесный конфигурируемый обработчик, который получает на вход изображения и преобразует их в документы с данными на выходе. Число таких объектов в одном процессе ограничено только доступными ресурсами. Процессоры можно создавать каждый раз перед использованием или кэшировать (в этом случае экономим на времени загрузки определений документов).

Для работы процессор требует задать набор определений документов. Определения документов можно загружать готовыми из файлов на диске, как в примере, либо из потока байтов в памяти, что позволяет хранить эти объекты в произвольном хранилище (ресурсы приложения, БД, разделяемое сетевое хранилище и т.п.). Можно также создавать определения документов на лету с нуля либо на основе «гибкого» или «жёсткого» описания геометрической разметки. (Как правило, рекомендуется использовать готовые шаблоны, созданные и отлаженные с помощью визуальных инструментов FlexiCapture. Программное создание или модификация определений может быть востребована, например, для упрощения сопровождения в случае, когда требуется работать с семействами похожих бланков, геометрия которых меняется из года в год, а семантика данных более-менее сохраняется).

Используя процессоры, можно организовать многоуровневую обработку, когда один процессор на входе выполняет первичную классификацию документов по каким-то простым признакам и отдаёт результат одному из более специализированных процессоров, который уже определяют точный тип документа и извлекает данные. Такой подход позволяет повысить производительность при работе с большим числом различных типов документов. Кроме того, специализированные процессоры могут работать параллельно, дополнительно повышая пропускную способность всего решения.

Входные изображения


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

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

Интерфейсу очереди изображений в некоторых случаях можно непосредственно сопоставить объекты целевого приложения, представляющие хранилище изображений в системе документооборота, пользовательскую реализацию «пакета документов» и т.п. Эти объекты для выполнения своей логики могут приватно реализовать этот интерфейс.

Цикл обработки


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

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

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

Работа с результатами


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

Данные из документа можно извлекать напрямую и самостоятельно сохранять в файлы или в БД (в том числе необходимые участки изображений) или пускать в дальнейшую обработку. Можно также экспортировать данные с использованием встроенных инструментов экспорта в файловые форматы.

Можно также сохранить документ как промежуточный результат в файл или поток в памяти для маршалинга или дальнейшей обработки в другом месте и в другое время. Такой дальнейшей обработкой может быть, например, верификация данных с помощью встроенных инструментов верификации.

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

Пользовательский механизм разрешения ссылок


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

Переопределение механизма разрешения ссылок позволяет пользователю полностью перестроить механизм работы со ссылками в контексте данного процессора под свои нужды. Ссылка рассматривается просто как некоторая строка, понятная этому механизму. Это может быть некоторый url или идентификатор в БД или комбинация таковых с указанием протокола. От переопределённого механизма разрешения ссылок требуется только умение вернуть для этой строки путь к локальному (временному) файлу на диске или поток байтов в памяти. Дополнительно при работе со ссылками определён протокол управлением временем жизни возвращаемых объектов (чтобы временные файлы своевременно удалялись, а объекты из памяти выгружались).

Заключение


Большая часть описанного в данной статье охвачена примерами, поставляемыми с продуктом. Это позволяет разработчикам, использующим наши технологии, начинать работу с уже проверенного работающего решения и развивать его под свои нужды. Примеры охватывают такие типы приложений как:
  1. Настольные приложения (использует отдельный процессор, загружаемый непосредственно в процесс пользователя, изображения в виде списка файлов на диске)
  2. Высокопроизводительный многопоточный сервер обработки (используется пул обрабатывающих процессоров, берущих изображения из разделяемой очереди)
  3. Web-сервис (пул обрабатывающих процессоров, которые параллельно обрабатывают параллельные клиентские запросы)
Также есть специальный пример (Code Snippets), написанный специально программистами для программистов и содержащий множество готовых выверенных коротких сценариев использования продукта ровно в том виде (без ошибок перевода :) ), как это задумывалось разработчиками и тестировалось.

Есть отличная справка, где подробно описаны все объекты и методы и их использование.

Более подробно об ABBYY FlexiCapture Engine 9.0 вы можете прочитать на сайте ABBYY.

Алексей Калюжный
Департамент продуктов для разработчиков
Теги:
Хабы:
+16
Комментарии19

Публикации

Изменить настройки темы

Информация

Сайт
www.contentai.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия

Истории