Всем привет!
В своих постах мы часто пишем о разных этапах систем распознавания документов (например, тут и тут). Настало время рассказать о еще одной задаче (и нашем решении для нее), которая часто опускается из подробного рассмотрения.
Наверняка каждый из вас хоть раз клал лист в сканер перевернутым (ну или вы очень везучи). Человек в случае такой оказии может повернуть изображение в редакторе или немного повертеть головой, а что делать системе распознавания?
Просто взять и проигнорировать перевернутые изображения нельзя, ведь при обработке больших объемов данных, например, цифровизации архивов, таких изображений может быть множество. При этом попытки запустить OCR-модели на перевернутых строках обычно заканчиваются плачевно – мы получаем случайные последовательности символов.
Давайте разбираться по порядку!
А что делают в известных системах?
В научных публикациях этот вопрос, как мы уже говорили, обычно опускают, так как он появляется в рамках разработки цельной системы распознавания. Так, при детекции текста его перевернутость не играет роли, а при решении задачи распознавания строки предполагается, что ее уже повернули в нужную сторону.
В документации закрытых систем распознавания, например, в Microsoft Azure и Amazon Textract, можно найти подтверждения того, что определение ориентации там присутствует, но описания применяемых методов нет. В результате, хоть что-то понять можно лишь об открытых системах распознавания, и мы решили посмотреть на две популярные: PaddleOCR и Tesseract OCR. Задача определения ориентации текста (то есть, его перевернутости) решается в этих системах по-разному: в Paddle OCR сделан упор на нейросетевой подход, а в Tesseract OCR – на классические подходы с голосованием.
В Paddle OCR используется легкий классификатор переворота строки на основе MobileNetV3 Small (x0.35). При этом, все найденные текстовые строки на изображении считаются независимыми, то есть, классификатор вполне может сказать, что одна строка перевернута, а другая – нет, и распознаваться они будут в разных ориентациях.
В Tesseract OCR v5 задача определения переворота строки решается по-другому и объединяется с решением задачи определения письменности (написан текст латиницей или арабицей, а может китайскими иероглифами). В основе их подхода лежит простое предположение: если в детектор письменности подать одну и ту же строку в разных ориентациях, то на правильной ориентации уверенность лучшего класса в среднем будет значительно выше, а на неправильной – распределение уверенностей альтернатив будет ближе к равномерному. В результате, в Tesseract OCR задачу определения ориентации решают без создания дополнительного классификатора. Более того, в Tesseract OCR итоговое решение принимается на весь документ сразу, путем агрегации результатов по строкам.
Оба этих подхода имеют свои плюсы и минусы. Так, подход Tesseract OCR более пригоден для документов, ведь в них большая часть текста, в особенности текста, содержащего важные реквизиты, написана в одной ориентации. Подход же PaddleOCR хорош именно отдельным классификатором, улучшение которого не задевает остальные подсистемы.
А что же делаем мы?
Изначально было понятно, что принимать решение нужно на весь документ целиком, иначе ошибки детектора могут привести к необъяснимым для пользователя ошибкам, когда большая часть документа распознана отлично, а в отдельных реквизитах – случайные последовательности символов.
При этом на первых этапах казалось, что можно (чем-то похоже на Tesseract OCR) обойтись без дополнительных детекторов, а принимать решение на основе распознавания. Идея была простой: сначала распознаем текст на документе в той ориентации, в которой он к нам пришел, а если средний конфиденс распознавания будет низким, то перевернем и проверим, станет ли лучше.
В качестве временного решения такой подход работает вполне хорошо, но быстро встают два важных вопроса: скорость и масштабируемость, причем в данном подходе эти важные параметры друг другу противоречат. Если мы опираемся на распознавание строк, то при добавлении документов на новых языках, нам нужно добавлять перебор языков, тем самым в разы замедляя систему.
В результате, подход на основе уже имеющихся классификаторов был признан неудачным и было решено обучать отдельный классификатор для переворота текста.
На проектируемый классификатор были наложены следующие ограничения:
детектор должен быть легким и быстрым;
детектор должен работать на разных письменностях (и не забывать строки, состоящие только из цифр);
детектор должен быть устойчив к инвертированным изображениям (к белому тексту на черном фоне).
В результате был обучен полносверточный нейросетевой детектор следующей архитектуры с 
параметрами и квантованными весами для большей скорости.
Однако только сети недостаточно для определения ориентации документа, ее необходимо использовать как часть общего алгоритма, который должен быстро и устойчиво определять перевороты разных документов.
Итак, на вход наш алгоритм получает страницу документа в неопределенной ориентации и результаты работы детектора текста на этой странице, а на выход должен сказать, требуется ли повернуть страницу на 180 градусов.
Мы используем итерационный алгоритм, который состоит из следующих шагов:
Выбираем 30% от общего числа задетектированных строк для текущей итерации. В целом, порог можно регулировать, но экспериментально было получено, что 30% зачастую оказывается достаточно для того, чтобы потребовалась всего одна итерация. При этом, выбираем тексты для рассмотрения мы следующим образом:
Минимальное расстояние от строки до границы листа должно превышать заранее заданный порог.
Из текстов, удовлетворяющих п.1.1, берутся самые удаленные от центра листа в порядке уменьшения расстояния (некоторый хак, повышающий устойчивость работы алгоритма).
Запускаем детектор переворота для каждой выбранной строки и агрегируем результаты:
Если число перевернутых строк более, чем в 1.5 раза больше числа прямых, то лист нужно повернуть на 180 и закончить анализ.
Если число прямых строк более, чем в 1.5 раза больше числа перевернутых, то лист поворачивать не надо и надо закончить анализ.
Если условия из 2.1 и 2.2 не выполнены, то надо продолжать анализ, вернувшись к п.1, если строк еще достаточно.
Если 2.1 и 2.2 не выполнены, но уже рассмотрены все доступные строки, то документ не поворачивается.
На рисунке ниже представлена схема описанного алгоритма.
Замеры качества
Для теста мы взяли открытый датасет DocBank, а точнее его подмножество из 30000 изображений, доступное на Kaggle. Оригинальный DocBank содержит полмиллиона страниц из различных научных статей с arXiv с аннотациями в JSON/XML форматах для замеров качества решения задач разбора и распознавания документов. В подмножестве с Kaggle хорошо сбалансировано разнообразие шаблонов (лэйаутов) и содержания документов, представленных в основном датасете. Для теста мы взяли данные страницы в оригинальной правильной ориентации и те же 30000 страниц в перевернутом варианте и сравнили наш подход с подходами, реализованными в PaddleOCR и Tesseract OCR.
Сначала немного технических деталей. Tesseract OCR запускался с отключенным распознаванием строк в режиме image_to_osd через интерфейс pytesseract. Для PaddleOCR распознавание также было отключено, а дополнительно была реализована логика выбора общей ориентации листа на основе ответов построчного детектора.
Мы получили следующие результаты, представленные в таблице ниже.
Ориентация | Наш подход | PaddleOCR | Tesseract OCR |
Прямая | 99.24% | 99.84% | 82.57% |
Перевернутая | 99.14% | 98.79% | 58.86% |
По таблице можно заметить, что PaddleOCR показывает качество выше, чем у нашего метода на прямых картинках. Однако его качество на перевернутых изображениях значительно ниже и качества нашего метода, и, что самое важное, качества самого PaddleOCR на прямых изображениях, а значит в случае большого числа перевернутых страниц (например, если пачку бумаги в потоковый сканер положили не той стороной) качество всей системы распознавания значительно просядет. Наш же детектор гораздо стабильнее.
Нам было важнее не максимальное качество на «удобном» случае, а одинаково устойчивое поведение системы независимо от того, какой стороной пользователь подал документ.
Ещё немного про качество
Рассмотрим подробнее отдельные примеры ошибок нашей системы и PaddleOCR. На всех приведенных иллюстрациях красным выделены отрезки текста, определенные как перевернутые, а синим – как прямые.
Пример 1. Перевернутый текст с формулами внутри.
В рамках нашей системы детектор текста выделяет строки целиком, в то время как подход в PaddleOCR делит их на отдельные слова и символы. Особо критично, что в такую излишнюю разбивку попадают симметричные символы, которые сбивают с толку детектор переворота. В итоге, на данном примере PaddleOCR ошибается.
Пример 2. Страница с диаграммой.
На данном примере наша система ошиблась, потому что детектор текста сработал на символах в вершинах диаграммы, которые тоже оказались достаточно симметричными (подстрочные символы у Х помочь не смогли).
На приведенных примерах наглядно видно, что ошибки системы связаны не столько с самой сетью, сколько с предварительными подсистемами, а значит нам еще есть куда расти.
Немного про скорость
Как вы знаете, мы в Smart Engines распознаем документы на всём, что считает, а значит предлагаемые алгоритмы должны быть максимально быстрыми. В проведенных экспериментах получены следующие значения времени определения ориентации для одной страницы
Система | Наш подход | PaddleOCR | Tesseract OCR |
Время, мс | 15.06 | 59.61 | 50.68 |
Вместо заключения
В промышленных системах распознавания качество определяется не только точностью распознавания символов. Можно иметь отличный распознаватель текстовых элементов и всё равно получить плохую систему, если ошибиться на одном из подготовительных этапов — определить ориентацию, найти текст, восстановить структуру или выбрать неправильный сценарий обработки.
Детектор ориентации — маленький компонент большой системы. Но именно из таких «маленьких» компонентов в итоге и складываются проценты качества, которые видит пользователь.
Хотели бы видеть еще посты о небольших, но важных кубиках-компонентах, из которых строятся большие промышленные системы?
