Распознать текст на скане документа – задача не новая. А вот уложиться в пару секунд на CPU – уже вызов.
Там, где готовые фреймворки долго "думают", я сделала своё OCR решение на основе PaddleOCR с конвертацией в ONNX. На выходе - ускорение более чем в 4 раза (по сравнению с исходным фреймворком) и полный контроль на каждом этапе: от распознавания текстовых областей до финальной выдачи символов.
В этой статье я расскажу почему в качестве ядра был выбран Paddle, и как работает весь алгоритм на основе его моделей.
Выбор ядра и отказ от "коробочного" решения
Когда речь заходит о задаче чтения текста с картинки (OCR – optical character recognition), часто первая рекомендация – это EasyOCR. А ещё есть Tesseract, OmniParser... а что такое PaddleOCR?
Разберём популярные варианты:
Tesseract — проверенный временем, открытый. Но главный его недостаток – отсутствие поддержки GPU. Сегодня это не просто конкурентное преимущество, а критическое требование для сервиса, который планирует обрабатывать большие объёмы запросов. Поэтому Tesseract был исключён из конкуренции даже без проверки качества распознавания текста.
EasyOCR — очень популярен и с хорошей репутацией. Даже есть поддержка рукописных шрифтов (это большой плюс). Однако особенности его использования делают его тяжёлым для промышленного инференса, особенно на CPU. Установка EasyOCR неизбежно тянет за собой PyTorch, который занимает несколько ГБ на диске. Но дело не ограничивается только расходованием физической памяти, PyTorch потребляет много оперативной памяти в моменте, что замедляет параллельную обработку.
OmniParser — современный, но избыточно сложный и, из-за этого, медленный. На первом этапе он находит объекты интерфейса с помощью YOLO, а затем встроенный OCR извлекает текст из UI-блоков. Для задачи «просто прочитать текст» такой подход избыточен: вместо компактного OCR используется ещё и CV-алгоритмы.
И тут появляется Paddle. Три причины почему я выбрала его:
Самый быстрый на CPU и GPU. Можно предсказуемо переключать инференс и не ограничиваться отсутствием GPU у клиента. Уже на СPU (16 ядер, 32 ГБ RAM) максимально долгий инференс занимал 1.5 секунды. А если GPU есть, то получаем ещё больше скорость – до 0.2 с на изображение на NVIDIA GeForce RTX 3090.
Лучшая точность на русско-английских текстах. Это подтверждают метрики качества текста.
Метрика
PaddleOCR
EasyOCR
WER (кол-во ошибок на 1 слово)
0.056
0.12
CER (кол-во ошибок на 1 символ)
0.016
0.03
ROUGE-1 (% общих слов с эталоном)
97.5
95.6
ROUGE-L (% общей последовательности с эталоном)
95.3
90.8
ONNX совместимость. PaddleOCR легко конвертируются в ONNX (Open Neural Network Exchange) формат и запускается через ORT (OnnxRunTime) сессии. Это даёт прирост скорости и управление CUDA-памятью не хуже, чем на C++. В случае с EasyOCR, официальной поддержки ONNX (без правок исходного кода) нет.
Если PaddleOCR уже есть "из коробки", зачем писать свой сервис?
1) Пример использования PaddleOCR фрейморка:
pip install paddlepaddle
pip install paddleocr
from paddleocr import PaddleOCR
ocr = PaddleOCR(lang='ru') # c настройками по умолчанию
result = ocr.predict(image_path)2) Ссылка на публичный сервис с Paddle в onnxruntime: https://github.com/PaddlePaddle/PaddleOCR/tree/main/deploy/paddle2onnx
И туториал по его настройке на Habr: https://habr.com/ru/articles/933634/
Результаты тестирования готовых решений на основе PaddleOCR были неудовлетворительными. Не хватало скорости и гибкости в постобработке результатов оцифровки. Например, так как формат выхода фиксирован, то нельзя было вернуть только текст с крупных текстовых блоков, игнорирую отдельно стоящие символы. Также хотелось группировать текстовые блоки по смыслу, находить заголовки окон / документов на картинке.
Когда я собрала свой пайплайн, оказалось, что кастомный OCR – это:
Быстро: инференс в 4 раза быстрее стандартного PaddleOCR фреймворка и в 2 раза быстрее ONNX решения
Гибко: запуск на CPU или GPU без переписывания кода
Контролируемо: легко экспериментировать с качеством моделей и добавлять необходимую постобработку результатов
Как устроен PaddleOCR + ONNX
PaddleOCR – это ансамбль из трёх последовательных нейросетевых моделей:
cls – определяет, не перевёрнут ли текст (0°, 90°, 180°, 270°)
det – находит все блоки с текстом на изображении
rec – читает символы внутри каждого блока
Все модели мы сохраняем в ONNX и запускаем через onnxruntime.
CLS: проверка поворота
Модель cls - это свёрточная нейронная сеть, которая классифицирует угол поворота входного изображения по 4 классам: [0, 90, 180, 270] градусов.
На выходе – вероятности для каждого из четырёх вариантов угла поворота. Выбирается угол с максимальным значением вероятности, и при необходимости изображение поворачивается перед подачей в детектор.
На практике cls этап опционален. Если все картинки заведомо ориентированы правильно (например, скриншоты экрана), cls этап можно пропустить: детектор сам справится с отклонениями перспективы до 10 градусов. Однако, хоть и пропуск cls ускоряет обработку, но в случае неожиданной подачи перевёрнутого изображения в det модель точность резко упадёт.
DET: поиск текста
Вход детектора: изображение, которое приведено к рекомендованному размеру – часто это 960 х 960 пикселей. Здесь важно, чтобы размеры сторон были кратны 32 – требование, исходящее из архитектуры свёрточных слоёв модели.
Внутри детектора (архитектура v5): изображение проходит через ResNet - сверточную нейронную сеть с остаточными связями. Благодаря этим связям (skip connections) градиент в ResNet не затухает, что позволяет строить очень глубокие сети, способные выделять сложные признаки текстовых полей: находить линии и углы букв, различать контраст между текстом и фоном и т.д.
Выход: сеть создаёт карту вероятностей (probability map), где для каждого пикселя исходной картинки указывается вероятность: "это текст" (близко к 1) или "это фон" (близко к 0).
Постобработка: метод DB (дифференцируемая бинаризация) позволяет на размытой карте с нечёткими границами областей выделить прямоугольники (bounding boxes), внутри которых средняя вероятность наличия текста выше заданного порога (обычно 0.6).
По координатам полученных прямоугольников из исходного изображения вырезаются области с текстом и передаются дальше – на распознавание (REC).
REC: распознавание символов
Вход дешифровщика:
Текстовая область – вырезанный прямоугольник из исходного изображения. Перед подачей в модель эта картинка масштабируется так, чтобы высота соответствовала фиксированным параметрам входа rec модели.
Словарь (charset) – набор символов в фиксированном порядке, на котором обучалась модель. Размер словаря должен совпадать с размером выхода rec модели.
Внутри дешифровщика (архитектура v5): Cвязка из трансформера (SVTR) и лёгкой свёрточной сети (LCNet) вычисляет вероятности для каждого символа из словаря на каждой позиции текстовой строки.
LCNet быстро извлекает визуальные признаки со всего изображения (линии, углы, контраст). Полученная карта признаков разбивается на мелкие патчи, которые поступают в SVTR.
SVTR анализирует патчи в двух режимах: локальном (соседние патчи) и глобальном (все патчи). Так модель учится выделять буквы (комбинируя несколько патчей) и одновременно понимать их порядок.
Выход: Матрица вероятностей размером (seq_len, n_classes), где:
seq_len – длина текстовой строки (количество найденных символов, включая пробелы и пустые символы)
n_classes – размер словаря
Постобработка: В самой простой реализации используется argmax - на каждой позиции выбирает наиболее вероятный символ. Полученная последовательность склеивается в итоговую строку текста.
Конвертация в ONNX: необходимая деталь
Конвертация в ONNX освобождает инференс от привязки к окружению PaddlePaddle. Модель становится независимой от фреймворка – можем встраивать вызов модели в python код. Набор операций, их порядок и веса сохраняются в стандартизированном формате.
Но откуда берётся ускорение?
ORT написан на C++ и отпускает GIL на время выполнения модели — вычисления идут параллельно и не блокируются интерпретатором Python. Помимо этого, внутри ORT работают оптимизированные операторы Intel MKL и NVIDIA cuDNN, выжимая максимум из процессора или видеокарты. А быстрая смена провайдеров (например, с CPUExecutionProvider на CUDAExecutionProvider) позволяет использовать один код на любом железе — от ноутбука до сервера.
OCR пайплайн шаг за шагом
Шаг 1. Готовые ONNX модели или конвертация
Проще всего взять готовые модели, уже сконвертированные в ONNX, с Hugging Face:
https://huggingface.co/monkt/paddleocr-onnx/tree/main/
Выбор моделей:
Детектор (det) не зависит от языка — его задача просто найти факт присутствия текста на изображении. Я взяла последнюю версию для китайского (PP‑OCRv5_ch_det). Китайский — родной язык компании‑разработчика PaddleOCR (Baidu), и эта модель показала себя лучше всех по полноте детекции текстовых блоков. Оценивала по WER: если детектор слабый, он пропускает целые слова, и ошибка растёт.
Распознаватель (rec) обязательно идёт в паре с набором символов — ключей для декодирования (charset.txt). Для смешанных русско-английских текстов я использовала модель eslav_PP-OCRv5_rec.
Конвертация своими руками (через paddle2onnx):
Если готовых моделей нужной версии нет, конвертируем вручную. Для этого скачиваем файлы обученной модели (inference.pdmodel и inference.pdiparams) и запускаем скрипт:
import os
import subprocess
def convert_cmd(model_dir, onnx_model_dir, model_name='det_v5_en'):
"""Ручная конвертация модели в onnx формат"""
os.makedirs(onnx_model_dir, exist_ok=True)
output_path = os.path.join(onnx_model_dir, model_name+".onnx")
cmd = [
"paddle2onnx",
"--model_dir", model_dir,
"--model_filename", "inference.pdmodel",
"--params_filename", "inference.pdiparams",
"--save_file", output_path,
"--opset_version", "12",
"--enable_onnx_checker", "True"
]
subprocess.run(cmd)Шаг 2. Создаём ORT сессии
import onnxruntime as ort
def create_onnx_sessions(det_model_path,
rec_model_path,
providers=['CPUExecutionProvider']):
"""Создание сессии ONNX runtime"""
sess_options = ort.SessionOptions()
det_session = ort.InferenceSession(det_model_path, providers=providers, sess_options=sess_options)
rec_session = ort.InferenceSession(rec_model_path, providers=providers, sess_options=sess_options)
print(f'rec_input_info [batch_size, colors, H, W] = {rec_session.get_inputs()[0].shape}')
print(f'rec_output_shape [batch_size, seq_len, classes] ={rec_session.get_outputs()[0].shape}')
return det_session, rec_sessionДетали настройки:
Выбор провайдера:
providers = ['CPUExecutionProvider'] # для CPUНастройки сессий (SessionOptions):
sess_options = ort.SessionOptions() sess_options.intra_op_num_threads = os.cpu_count() // 2 # потоки для вычислений (обычно = числу ядер) sess_options.execution_mode = ort.ExecutionMode.ORT_PARALLEL # параллельное выполнение (где возможно)При желании можно добавить другие настройки оптимизации. Для CPU можно ограничиться настройками по умолчанию, но на GPU важна их специализированная настройка.
Создание ORT сессий – для каждой модели своя:
session = ort.InferenceSession()Проверка размерностей входа и выхода моделей
# Вход распознавателя (eslav_PP-OCRv5_rec): [batch_size, channels (RGB), height, width] print(rec_session.get_inputs()[0].shape) # [1, 3, 48, -1] (-1 = динамическая ширина) # Выход распознавателя (eslav_PP-OCRv5_rec): [batch_size, seq_len, classes] print(rec_session.get_outputs()[0].shape) # [1, -1, 519]
Шаг 3. Детекция текстовых блоков
Вход: изображение в формате np.ndarray
Предобработка изображения - приводим изображение к формату, который ожидает модель детекции [batch_dim, channels, h, w]:
Масштабирование изображения с добавлением паддинга для кратности сторон 32
Нормализация цветовых каналов RGB с помощью констант:
mean = [0.485, 0.456, 0.0406], std = [0.229, 0.224, 0.225]Добавление batch_dim = 1 и перестановка осей тензора. Было
(h, w, channels),стало(1, channels, h, w)
Запуск модели детекции и получение карты вероятностей "текст / не текст"
Постобработка карты вероятностей:
Бинаризация карты вероятностей по заданному порогу уверенности
Поиск контуров (cv2.Countours)
Расчёт средней вероятности текста внутри контуров и фильтрация контуров с низкой уверенностью
Обратное масштабирование контуров – прямоугольников в размеры исходного изображения
Опциональная обработка результатов:
* Фильтрация текстовых блоков по геометрическим признакам – оставляем только вытянутые в ширину блоки
* Объединение близких блоков в один – для получения более связного текста при расшифровке
* Группировка координат центров блоков (с помощью DBSCAN, так как не знаем заранее число кластеров) для выявления смысловых блоков информации на картинке
Шаг 4 – детекция текстовых символов
Вход – координаты текстовых блоков с предыдущего шага
Предобработка:
Вырезание областей с текстом из исходного изображения (по координатам bbox)
Коррекция перспективы (cv2.getPerspectiveTransform())
Пропорциональное масштабирование: модель распознавания ожидает фиксированную высоту H.
Добавление batch_dim = 1 и транспонирование тензора для формата
[batch_size, channels, height, width]
Запуск модели распознавания и получение матрицы вероятностей
(seq_len, n_classes)для каждого индекса текстовой строки по символам из charset.Декодирование строки текста: проход по каждому символу последовательности и выбор индекса с наибольшей вероятностью (argmax). Далее преобразуем индексы в буквы с помощью словаря charset.txt.
Выход – распознанная текстовая строка.
Результаты
Вы можете проверить алгоритм на качество распознавания текста на ваших картинках: https://github.com/Natalia-Alexandrova/OCR-paddle-onnx/tree/main
Ключевые заметки
1) PaddleOCR в ORT сессии работает за пару секунд на мощном CPU и за доли секунды на GPU. Это уверенный кандидат на то, чтобы выдержать промышленную скорость.
2) Удобнее взять готовые paddle модели в onnx HF. Модель детектора не зависит от языка. Для распознавателя проверяем соответствие размерности словаря-дешифровщика (charset) с заданным выходом rec модели (n_classes).
3) Перед подачей в модели требуется масштабирование картинок. Для v5 это 960 пикселей - для модели детекции и h = 48 пикселей - для модели распознавания.