Применение Tesseract-OCR: распознавание чеков

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

Прототип решения

Прототип решения — по картинке понимать, чек это или нет. Если нет, то просить пользователя повторно сделать фото. Чеки попадают в систему через специальное мобильное приложение, которое фотографирует и отправляет изображение на сервер для дальнейшей обработки.

Как базовую утилиту для работы с изображениями мы выбрали Tesseract-OCR (Optical Character Recognition) — популярное open source решение, которое переводит изображение в текст, а задачу анализа изображения сводит к анализу текста.

Процесс работы с чеками проходит в три этапа:

  1. предварительная обработка изображения,
  2. преобразование в текст,
  3. извлечение данных.

Этап 1: предварительная обработка изображения

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

После передачи изображения на сервер используются фильтры и алгоритмы OpenCV (библиотеки компьютерного зрения). Для адекватной работы программы Tesseract с их помощью реализовано увеличение контраста и перевод изображения в черно-белое.

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

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

Таким образом, вопрос предварительной обработки изображения остается актуальным.

Этап 2: преобразование в текст

На этом этапе в работу вступает Tesseract-OCR, который выбран как open source решение с большим комьюнити (также рассматривали phpOCR, OmniPage Capture SDK). Облачные решения не рассматривали из-за безопасности персональных данных. Вот тут представлено сравнение решений OCR.

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

Этап 3: извлечение данных

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

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

Во-вторых, чек разбивается на компоненты: дату, название магазина, строки, количество и стоимость товаров. Эта задача решается отдельным процессом на сервере и занимает продолжительное время. По необходимости проводится ручная проверка администратором, если алгоритм не достиг успеха.

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

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

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

Резюме

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

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

0 комментариев

Новый комментарий