Написано Ришабх Джайн, Правин Дхинва, Викрам Гупта, Хастагири Ванчинатан, Дебдут Мукерджи
ShareChat — ведущая платформа социальных сетей в Индии, а Moj — платформа коротких видео номер один в Индии с одним из самых высоких ежемесячных активных пользователей. Оба позволяют пользователям делиться своим мнением и записывать свою жизнь, не выходя из предпочитаемого ими языка. Наш контент состоит из изображений и видео, большинство из которых создаются и загружаются нашими пользователями.
В Части 1 этого блога мы говорили о создании собственной системы OCR для наших изображений и видео, созданных пользователями. Мы говорили о проблемах с данными, обнаружении текста и шагах по распознаванию текста. Мы также коснулись того, почему текст, встроенный в видео и изображения, является чрезвычайно важной функцией для нас.
Хотя все это работает, наши данные гораздо более тонкие и сложные из-за нескольких языков и нашего варианта использования. Вот некоторые из проблем и их решения, которые мы обсудим в этой части:
Problem 1 :: Imperfect Bounding Boxes Problem 2 :: Support for multiple languages Problem 3 :: Box weaving for comprehensible fullText Problem 4 :: Relevant Text Extraction Problem 5 :: OCR on videos
Динамическое заполнение на выходе обнаружения текста
Как показано на рис. 1, ограничивающие рамки, сгенерированные алгоритмом обнаружения текста, несовершенны и часто укорочены по горизонтальной оси, что приводит к несовершенствам распознавания текста на последующих этапах. Это не вина алгоритма, а сама истина.
Обычный подход состоит в том, чтобы заполнить поля несколькими пикселями по горизонтали, чтобы покрыть все слово. Заполняйте коробки немного меньше, и мы все еще получаем неверные слова. Заполните блоки немного больше, и они могут привести к коллизиям или дополнительным блокам, которые будут препятствовать шагу распознавания текста, поскольку могут быть созданы бессмысленные слова или уменьшен размер фактического слова в ограничивающем блоке.
Следуя тем же принципам, мы сначала попытались добавить постоянный пиксель x к длине блока с каждой стороны. Но, поскольку коробки могут различаться по соотношению сторон и длине сторон, это не очень хорошо сказалось на наших показателях.
Затем мы попробовали отступы на основе процентов, когда каждая сторона длины увеличивается на x% для каждого блока. Этот подход работал немного лучше, но не на должном уровне. Причина заключалась в том, что увеличение было настолько незначительным, что едва ли имело значение для 1–2-символьных слов, а для 6–7-символьных слов расширение приводило к дополнительным отступам и коллизиям.
Итак, мы попробовали интуитивно понятный алгоритм динамического заполнения. Проще говоря, он одновременно увеличивает длину всех прямоугольников на изображении до фиксированного порога, чтобы они не сталкивались друг с другом, останавливаясь раньше, когда есть вероятность столкновения. Зеленые прямоугольники являются результатом алгоритма динамического заполнения на рис. 1 и выглядят лучше, чем исходные красные прямоугольники.
The exact algorithm we used is as follows: 1. Each box looks at the nearest box on its left and right that falls in its line-neighborhood. Line-neighborhood for a box is the region covered by the box on its extension, if its length-sides parallel to the horizontal-axis are extended until the end of the image on each side. 2. Each box of the image is expanded on the left side by a maximum of half the distance with its left neighbor and similarly on the right. The expansion is thresholded by a fraction of the original word box length as well. For one-off instances of boxes having no neighbors on some side, we set a max threshold based on the box length of the original box. Fig 2 illustratively shows the dynamic padding strategy.
Мы сравнили все методы заполнения, обучив распознаватель для каждого из них и сравнив показатели точности. Подход с динамическим дополнением значительно превзошел два других метода. Прямое преимущество динамического заполнения также можно увидеть на рис. 3.
Добавление новых языков
Модуль идентификации сценария
В ShareChat & Moj мы обслуживаем наших пользователей и авторов на более чем 15 индийских языках. Один из подходов заключается в обучении нашей модели распознавания текста, как упоминалось в части 1, путем объединения словарного запаса каждого языка. Для вычислительных целей обучение такой модели невозможно. Другой подход заключается в том, чтобы поместить модуль идентификации сценария перед модулем распознавания текста. Этот модуль лучше всего можно описать как проблему классификации изображений, в которой мы классифицируем изображения уровня ограничивающей рамки по одной из нескольких категорий на основе их сценариев. Английский язык не входит напрямую ни в один из 15+ языков нашей экосистемы, но по-прежнему присутствует в большом количестве, поскольку он присутствует в контенте на всех языках в значительной степени. пропорции.
Сценарий или модуль идентификации языка?
Многие индийские языки и диалекты имеют тот же список символов, что и другие индийские языки. Например, ассамский и бенгальский языки имеют один и тот же сценарий, а также раджастхани и бходжпури с хинди. Не имеет смысла использовать модуль идентификации языка вместо модуля идентификации скрипта, так как для первого данные будут, по сути, несовершенными. Поэтому вместо этого мы решили использовать модуль идентификации скрипта.
We faced two major challenges while developing the script identification module. 1. Enabling support for languages that share the same script. Languages like Hindi, Marathi, Bhojpuri etc share the same script, but have vastly different word vocabularies as shown in Fig 4. 2. How to handle the incorrect examples from our underlying data? Remember, our data issues from part 1 of the blog.
Чтобы справиться с первой задачей, мы поняли лингвистические особенности каждого языка и проверили наши наблюдения, увидев, какие символы являются общими для разных языков из наших данных. Наконец, мы получили исчерпывающий набор из 11 различных шрифтов: англо-латинский, деванагари, гурумукхи, бангла и т. д.
Чтобы справиться с второй проблемой неправильных примеров из наших данных, мы сначала попытались удалить их, используя подход, который использует словарь, созданный из наших данных, в сочетании со стандартным словарем слов на этом языке для удаления таких примеров. . С огромным количеством уникальных слов, он также удалил множество истинных примеров.
Затем мы проверили сценарий всех слов, присутствующих в наших данных, применительно к имеющемуся у нас постязыку. Кроме того, мы исправили, какие сценарии можно ожидать для определенного постязыка, основываясь на атрибутах лингвистических знаний нашей разнообразной команды по контенту. Основываясь на наших наблюдениях, мы обнаружили, что существует два разных вида ложных примеров:
- Слова индийского языка, которые не должны были присутствовать в этом постязыке.
- Слова, которые не являются ни английскими, ни индийскими по своему характеру. Мы назвали эту категорию Беседы и включили ее в качестве 12-й категории в наш модуль идентификации скриптов. Эта категория тарабарщины также помогла нам с ложными экземплярами, когда что-то выглядит как текст и обнаруживается нашим детектором, но отвергается (помечается как тарабарщина) нашим модулем идентификации скриптов. Один из примеров можно увидеть на рис. 5.
Наконец, мы обучили модель, похожую на модель классификатора изображений, и настроили ее для прогнозирования одной из 12 категорий сценариев.
Распознавание текста
Как только кадры идентифицируются с помощью определенного скрипта, мы отправляем их в распознаватель текста. Как обсуждалось в Части 1 этого блога, мы использовали ту же архитектуру для нашего шага распознавания текста. Просто словарный запас символов, которые мы использовали на каждом этапе, менялся в зависимости от каждого сценария.
Для создания словарного запаса для каждого скрипта мы использовали наиболее распространенные 94 символа для каждого языка. Для большинства скриптов они могут охватывать более 98% символов, доступных для этого языка. Идея использовать 94 символа пришла из английского языка, как описано в Часть 1, и мы придерживаемся этого, чтобы эффективно использовать его для трансферного обучения.
Мы использовали ту же архитектуру для наших одиннадцати скриптов, за исключением Тарабарщины, кадры которой отбрасываются и дальше не отправляются. Мы использовали предварительно обученные веса ASTER распознавателя одного скрипта для обучения другого. В итоге у нас было одиннадцать различных распознавателей текста, по одному для каждого сценария.
Скрипты, связанные с одним языком, хорошо справились с этой задачей. Но скрипты, например деванагри, который имеет несколько связанных языков (хинди, маратхи, бходжпури и т. д..), не смогли обобщить, если обучались на данных одного языка и тестировались на других языках с таким же скриптом. . Это связано с тем, что такие модели, как ASTER, по своей природе запоминают последовательность символов для формирования осмысленного слова. Поскольку разные языки используют один и тот же сценарий, нелегко обобщить такой набор звуков и символов. Итак, для обработки таких случаев мы разработали смешанный пакет данных, который состоит из всех таких языков одного скрипта на основе их пропорций в нашем трафике, но искусственно выделяя минимальную квоту для каждого из них.
На рис. 4 показан список некоторых языков, поддерживаемых в ShareChat и Moj, в сравнении с основными языками, которые мы использовали для создания словарного запаса на уровне символов.
Плетение коробок
Хотя наша проблема с внешней точки зрения похожа на OCR в дикой природе, основное отличие заключается в анализе содержимого. Мы должны уметь правильно выполнять задачи по обнаружению, идентификации и распознаванию и составлять контент таким образом, чтобы он был читаем и понятен людям, не говоря уже о моделях. Хотя на первый взгляд это кажется простой задачей, способ размещения фрагментов контента на фоне затрудняет понимание того, какой фрагмент комбинации изображения и текста что представляет? Связан ли он с чем-то другим, или его следует пересекать дальше, так как он представляет собой объединение многих независимых секций?
Сначала мы рассмотрели несколько подходов к глубокому обучению, которые могли бы решить проблему, но не смогли найти ни одного полезного для нас. В конце концов мы остановились на алгоритме Box-Weaving, который мы разработали и проверили с добавлением вручную аннотаций к некоторым образцам данных.
Here is our approach, 1. We compute each box's average box height and width and manually tune a height and width expansion ratio. We expanded each box in all four directions, using both of these factors. 2. Once expanded, some of these boxes intersect with each other. An edge joins the boxes that intersect in the graph space, where each node represents a box. 3. We use a connected-component algorithm to find individual components that can be a blob of the same text segment. 4. Finally, we arrange these segments in a top-down left-right approach based on their respective centers and sizes in the full-text generation. 5. We used a manually tuned vertical padding value to handle slightly rotated text lines to get the order of words inside each segment.
Мы также экспериментировали с обучением той же модели EAST на текстовых строках, чтобы получить ориентацию строк, но классический подход сверху вниз, слева направо превосходит подход глубокого обучения в нашем случае. Мы также понимаем, что это не сможет правильно сплести вертикальные и сильно повернутые текстовые строки, но у него не так много случаев для наших данных и поведения пользователя. Во-первых, на Рис. 5 и Рис. 6 приведены иллюстрации ткачества коробок.
FullText for Fig 5: <Seg1> জীবনটা অনেক ছােটো ! <Seg2> শুভ সকাল বন্ধুরা <Seg3> তাই হাঁসাে এমন করে যাতে কষ্টভ তােমার কাছে। এসে আনন্দ পায় ।
FullText for Fig 6: <Seg1> दोस्त दवा से भी ज्यादे अच्छे होते है क्योकि दवा तो expire हो जाती है.. <Seg2> --------(Not Relevant)-------- omessagekaro <Gibberish> more <Seg3> पर अच्छे दोस्तों की कोई expiry date नहीं होती.. <Seg4> good morning ji
Соответствующий экстрактор текста
При выводе полного текста не все слова полного текста нам жизненно важны. Часто веб-сайты, контактная информация, подпись автора и другие логотипы переплетаются с нашим полным текстом и приводят к тому, что дальнейшие модели в конвейере анализа содержания имеют ухудшенную производительность, чем они могли бы быть. Итак, мы создали соответствующий экстрактор текста, который использует полный текст из наших предыдущих шагов и другие атрибуты метаданных уровня ограничительной рамки, чтобы возвращать соответствующую информацию вместе с полным текстом.
Мы идентифицируем флаги, которые делают сегмент из модуля плетения коробок неактуальным для нас. Флаги обычно включают:
- Стоп-слова для логотипа
- Контактная информация
- URL-адрес
- Если размеры и количество ограничивающих рамок ниже определенного порога, мы отклоняем контент.
- Чтобы удалить подписи авторов, водяные знаки и торговые марки, мы используем другие атрибуты, в том числе соотношение сторон блоков, аномальные повороты, сценарии и различия в размерах между основным содержимым и другими блоками, а также их расположение относительно друг друга. до полного текста.
Мы сравнили результаты с ручной аннотацией и настроили параметры в соответствии с нашим вариантом использования. Результат одного такого случая показан на рис. 6, на котором объединены как модуль плетения блоков, так и соответствующий модуль извлечения текста.
Получение соответствующих кадров изображений из видео
Чтобы наш ShareOCR на основе изображений также мог решить проблему распознавания видео, мы применяем алгоритм декодирования видео для получения соответствующих кадров. Мы делаем это, сэмплируя кадры с видеовхода.
Here is our approach: 1. First, we decode the video using an FFMPEG decoder. The decoder breaks the video into frames and associates a value called scene-change-value s with each frame, which lies between 0 to 1, 0 indicating that the frame is the same as the previous frame, 1 indicating a high magnitude of dissimilarity between the current frame and the previous frame. 2. We take a set of at most 16 frames where the scene-change-value is more than a particular threshold. 3. These frames are then passed to a RESNET architecture, which generates a k-dimensional feature vector for each frame. We map them into k-dimensional space, and the top four frames most dissimilar to each other post RESNET are kept. 4. These four frames are then fed to our OCR model separately, which are combined and output for the complete video.
Заключительные замечания
Разработка ShareOCR была связана с интеграцией различных сетей глубокого обучения для каждой задачи и созданием алгоритмов для устранения различных неточностей данных и решения сложных, но нишевых проблем, которые возникли в нашем случае использования. Некоторые из этих уроков являются общими при работе с контентом на индийском языке, особенно с языками, которые сообщество AI не усвоило. Мы с нетерпением ждем ваших комментариев по ShareOCR.
Иллюстрация на обложке: Ritesh Waingankar
