Обзор исследований, инструментов и проблем в OCR

вступление

Я люблю OCR (оптическое распознавание символов). Для меня это представляет собой реальную проблему в науке о данных, и особенно в компьютерном зрении. Это реальная проблема, у нее много подходов, она включает в себя компьютерное зрение, настройку конвейера и даже немного НЛП. Это также требует большой инженерии. Он включает в себя многие проблемы науки о данных: подрыв надежного эталона, чрезмерный упор на сложность и «новизну» подходов вместо реального прогресса в мире.

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

Его суть заключалась в том, что в то время распознавание текста с глубоким обучением было хорошим, но не достаточно хорошим. В настоящее время OCR намного лучше. Но все равно не очень.

Однако, учитывая динамику области глубокого обучения, на мой взгляд, это требует обновления или, возможно, даже полного переписывания. Итак, вот оно. Если вы попали сюда, вы, вероятно, каким-то образом заинтересованы в OCR. Либо вы студент или исследователь, который хочет изучать эту область, либо у вас есть деловой интерес. В любом случае, эта статья должна вас познакомить.

Хотите узнать больше? посетите Shibumi-ai.com

Начиная

Во-первых, давайте уточним наши концепции:

  • OCR - Оптическое распознавание символов. Это общий термин, который в основном относится к структурированному тексту в документах.
  • STR - Распознавание текста сцены. В основном относится к более сложному тексту. Для простоты мы будем называть их обоих как OCR.

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

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

Вдобавок появилась отличная и полезная библиотека - Easy OCR, цель которой - сделать современные подходы OCR доступными и простыми в использовании с открытым исходным кодом. В качестве дополнительного удовольствия эта библиотека также решает проблему многоязычия в OCR (в настоящее время включает ~ 80 языков и больше) и скорость моделей (все еще на ранних стадиях). Эта библиотека не идеальна, но это действительно отличное решение. Подробнее об этом позже.

Итак, без лишних слов, давайте рассмотрим состояние OCR.

Заслуживающие внимания исследования

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

В своем предыдущем посте я рассмотрел 3 подхода:

  1. Популярный тогда подход классического компьютерного зрения.
  2. Общие подходы к глубокому обучению, обнаружению и распознаванию, которые были эффективными и простыми в использовании.
  3. Конкретные подходы глубокого обучения для OCR, такие как CRNN и STN, дали хорошие результаты, но были слишком новы, чтобы доверять.

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

Задания

В предыдущем посте мы использовали несколько примеров, которые могут выглядеть просто в текущем состоянии: распознавание автомобильных номеров, распознавание капчи и так далее. Сегодняшние модели более эффективны, и мы можем обсуждать гораздо более сложные задачи, такие как:

  • Разбор скриншотов
  • Разбор коммерческих буклетов
  • Разбор цифровых медиа
  • Обнаружение уличного текста

Трубопровод

После применения стандартных методов обнаружения и сегментации объектов к OCR подходы стали становиться более конкретными и адаптированными к текстовым атрибутам:

  • Текст однороден - каждая часть текста по-прежнему является текстом.
  • Текст может быть обнаружен на разных уровнях: символы, слова, предложения, абзацы и т. Д.

Таким образом, современные подходы OCR «изолируют» определенные характеристики текста и используют конвейер различных моделей для их решения.

Здесь мы собираемся сосредоточиться на определенной настройке, фактически на конвейере моделей, которые помимо модели видения (средства извлечения признаков), есть еще несколько полезных компонентов:

  1. Первая часть конвейера - это обнаружение текста - наиболее интуитивно понятное разделение. Понятно, что если вы собираетесь использовать разные части, определение того, где находится текст, до распознавания реальных символов может быть хорошей идеей. Эта часть обучается отдельно от других.
  2. Вторая часть конвейера необязательна - слой преобразования. Его цель - обработать искаженный текст всех видов и преобразовать его в более «обычные» настройки (см. Рисунок конвейера)
  3. Третья часть - это средство извлечения функций зрения, которое может быть вашей любимой глубокой моделью (но старый добрый ResNet, конечно, работает лучше всего).
  4. Четвертая часть конвейера - это RNN, предназначенная для изучения повторяющихся текстовых последовательностей.
  5. Пятая и последняя часть - это убыток CTC. Недавние работы заменили его на внимание.

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

Трубопровод «болезнь»

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

Наборы данных

Известно, что основа всей хорошей работы в области науки о данных - это наборы данных, а в OCR они имеют решающее значение: на результаты критически повлияли выбранные наборы данных для обучения и тестирования. За прошедшие годы задача OCR отточила около десятка различных наборов данных. Однако большинство из них не содержало более нескольких тысяч аннотированных изображений, что казалось недостаточным для масштабирования. С другой стороны, задача OCR - одна из самых простых в использовании синтетических данных.

Давайте посмотрим, какие доступны известные наборы данных:

«Настоящие» наборы данных

Несколько наборов данных использовали массовый охват Google Street View. Эти наборы данных можно разделить по их ориентации на регулярные или неправильные (искаженные, угловые, закругленные) тексты.

SVHN - номера просмотра улиц, которые мы использовали для примера в предыдущем посте.

SVT - текст просмотра улиц - текстовые изображения из просмотра улиц Google

ICDAR (2003, 2013,2015, 2019) - некоторые наборы данных, которые были созданы для конвенции и конкурса ICDAR с разным акцентом. Например, наборы данных 2019 года называются «текстом произвольной формы», что означает, что они настолько нерегулярны, насколько это возможно.

Синтетические наборы данных

Есть 2 популярных синтетических набора данных, которые использовались в большинстве работ по распознаванию текста. Непоследовательное их использование затрудняет сравнение произведений.

MJ Synth - включает относительно простые словосочетания. Сам набор данных включает около 9 миллионов изображений.

Synth текст - более сложный механизм, который применяет сегментацию и оценку глубины изображения на первом этапе, а затем засаживает текст на предполагаемые поверхности. Сам набор данных включает ~ 5,5 млн изображений.

DALL-E - немного дикая карта, но будущее генерации текстовых изображений (и, возможно, OCR) кажется гораздо более бесконтрольным.

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

Метрики

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

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

Теперь самое интересное - признание. Есть два основных показателя: точность на уровне слов и точность на уровне символов. Конкретные задачи могут использовать даже более высокие уровни точности (например, точность фрагментов текста). Современные методы обеспечивают ›точность 80% сложных наборов данных (мы обсудим это позже).

Сам уровень символа заключен в «Нормализованное расстояние редактирования», которое измеряет соотношение одинаковых символов в словах.

Научно-исследовательские работы

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

Что не так с распознаванием текста сцены?

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

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

Итак, ключевые моменты этой статьи:

  1. Наборы данных для обучения (которые можно считать «лучшими») для OCR - это 2 синтетических набора - MJ и Synthtext. Более того, важными особенностями являются не количество, а разнообразие (уменьшение количества данных не сильно повлияло на производительность модели, а вот удаление одного из наборов данных повредило)
  2. Наборы тестовых данных были ~ 5 наборами данных реального мира.
  3. Бумага демонстрирует постепенное улучшение результатов с каждым обновлением конвейера. Наиболее значительным улучшением точности с 60% до 80% было улучшение функции извлечения функций из VGG в ResNet. Следующие добавления RNN и нормализации подняли модель до 83%. Обновление CTC к вниманию добавило 1% точности, но утроило время вывода.

Обнаружение текста

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

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

КРАФТ

Наш любимый метод обнаружения объектов, который также интегрирован в Easy OCR, называется CRAFT - распознавание области символов для обнаружения текста. Этот метод применяет простую сеть сегментации и прекрасно использует как реальные, так и синтетические изображения, а также аннотации на уровне символов и слов.

Эта модель привела к ~ 80% H-среднему (по P и R) и большинству наборов данных, а также очень хорошо справляется с разделением слов, чтобы облегчить жизнь моделям распознавания.

Практические примеры

Мы подошли к практической стадии. Что использовать? Итак, мы в основном ответили на этот вопрос ранее (Easy OCR…), но давайте рассмотрим несколько популярных решений.

Открытый исходный код

Следует отметить одну очень важную вещь: хотя OCR страдает недостаточной надежностью в академической среде, оно пользуется процветанием программного обеспечения с открытым исходным кодом, что позволяет исследователям и практикам опираться на работу друг друга. Предыдущие инструменты с открытым исходным кодом (например, Tesseract, см. Ниже) боролись со сбором данных и разработкой с нуля. Последние пакеты, такие как easy OCR, включают в себя набор строительных блоков, от генерации данных до всех моделей конвейера и других настроек.

Инструменты

Тессеракт

Долгое время Tesseract OCR был ведущим инструментом OCR с открытым исходным кодом (не считая случайных репозиториев, связанных с бумагой). Однако этот инструмент был построен как классический инструмент компьютерного зрения и плохо прошел переход к глубокому обучению.

API

OCR были одними из первых API компьютерного зрения крупных облачных провайдеров - Google, Amazon и Microsoft. Эти API не предоставляют каких-либо критериев их возможностей, поэтому мы несем ответственность за тестирование

Easy OCR

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

Вот как это работает:

  1. Генерация данных с помощью пакета MJ-Synth.
  2. Модель КРАФТ (см. Выше) для обнаружения.
  3. Обучение измененного конвейера на основе статьи «что не так» (см. Выше) для распознавания текста.
  4. Прочие оптимизации.
  5. Многоязычный: как уже говорилось, OCR содержит некоторые элементы НЛП. Следовательно, обработка разных языков имеет различия, но также и сходства, которые мы могли бы извлечь из модели CRAFT (и, возможно, других моделей обнаружения), являются многоязычными. Модели распознавания зависят от языка, но процесс обучения такой же, с некоторыми тиками (например, иврит и арабский - это RTL, а не слева направо)

Последний фрагмент головоломки, который на данном этапе делает ее «технологией OCR», - это производительность. Ниже вы можете увидеть, что они даже лучше, чем результаты платных API.

Одна вещь, которую нужно улучшить в Easy OCR, - это возможность настройки: хотя выбор языка прост, изменение моделей и переподготовка для разных целей. В следующем посте мы покажем, как это сделать.

А как насчет времени выполнения?

Неудивительно, что вывод OCR может быть медленным. Модели обнаружения - это стандартная модель глубокого обучения, которая выполняется за ~ 1 секунду на графическом процессоре (на изображение), в то время как модели распознавания запускаются снова и снова при обнаружении. Изображение с множеством элементов может занять несколько десятков секунд на графическом процессоре, не говоря уже о процессоре. Что делать, если вы хотите запустить OCR в своем мобильном приложении или приложении для ПК, используя более слабое оборудование?

Easy OCR может помочь вам: во-первых, библиотека предлагает некоторые уловки для более быстрого вывода (например, более плотную форму фрагментов изображения для распознавания объектов). Кроме того, будучи модульным, можно (в настоящее время с некоторой доработкой кода) интегрировать свои собственные модели, которые могут быть меньше и быстрее.

Примеры кода

Итак, после обсуждения различных пакетов и моделей, пришло время увидеть реальные результаты. Зайдите в эту записную книжку colab, чтобы попробовать Easy OCR vs Google OCR vs Tesseract. Я выбрал два изображения:

Один из них - распространенный случай OCR - стандартный структурированный текст из документа, а второй - сложная коллекция обложек книги: много шрифтов, фонов, ориентации (не так много) и так далее.

Мы попробуем три варианта: Easy OCR, Google OCR API (который считается лучшим среди API крупных технологических облаков) и старый добрый Tesseract.

PDF

Для этого типа текста хорошая производительность Tesseract и Google OCR идеальна. Это имеет смысл, поскольку Google OCR может каким-то образом основываться на Tesseract.

Обратите внимание, что в Google OCR есть специальный режим для этого вида текста - DOCUMENT_TEXT_DETECTION, который следует применять вместо стандартного TEXT_DETECTION.

Точность Easy OCR составляет около 95%.

Сложный образ

В целом результаты Easy OCR были лучшими. в частности, компонент обнаружения улавливал около 80% предметов, в том числе очень сложных по диагонали.

Google OCR как-то хуже, около 60%.

По признанию, они были примерно на одном уровне - около 70% на уровне персонажей, что делало их не такими хорошими на уровне слов или книг. Кажется, что Google OCR не был на 100% правильным для одной книги, в то время как Easy OCR имел несколько.

Еще одна вещь, которую я заметил, это то, что, хотя Easy OCR лучше работал с символами, Google OCR хорошо работал со словами, что заставляет меня думать, что он может использовать словарь за кулисами.

Резюме и будущее

Надеюсь, вам понравился этот пост.

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

Недавние модели Open-AI - Clip и Dall-e - продемонстрировали некоторое «неконтролируемое» понимание OCR

В следующих постах мы закатим рукава и:

  • Посмотрите, как мы можем настроить платформу Easy OCR для наших целей
  • Работаем над обучением специальной системы распознавания текста для наших целей.

Будьте на связи!

Использованная литература:

  1. Что не так со сравнениями моделей распознавания текста в сценах? Набор данных и анализ моделей - Baek et al.
  2. Осведомленность области символов для обнаружения текста - Baek et al.
  3. Https://github.com/PaddlePaddle/PaddleOCR - Этот пакет OCR недавно был в тренде на GitHub, но у нас еще не было возможности его протестировать.
  4. Мой предыдущий пост про OCR

Хотите узнать больше? касса Shibumi-ai.com