Русский
Русский
English
Статистика
Реклама

Распознавание документов

Ковидная индустрия и системы распознавания

21.04.2021 14:19:32 | Автор: admin

Прошло больше года с момента введения жестких ограничительных мер, связанных с распространением COVID-19. Сейчас мир постепенно возвращается в нормальный режим жизни, хотя угроза новых вспышек заболевания остается. Поэтому принимаются все необходимые меры: маски, перчатки и сдача ПЦР-тестов по разным поводам. С административной точки зрения, это, скорее всего, правильно. А вот с организационной система не готова. Главная проблема слабо организованная система проведения ПЦР-тестов. В сегодняшней статье поговорим о том, как ее усовершенствовать.

С точки зрения организации администрирования всего процесса, в целом, ПЦР-тестирование это не просто мазок из носоглотки. Необходимо организовать следующие процессы:

  • регистрация клиента и взятие мазка из ротоглотки ПЦР-теста (в стационарных или мобильных пунктах);

  • логистика биоматериала до исследовательской лаборатории;

  • проведение анализа биоматериала;

  • предоставление результатов тестирования;

  • контроль результатов на пропускных пунктах (в аэропортах, гостиницах, офисах и т.п.).

Оказывается, в качестве bottle neck в приведенном списке выступают первая и последняя позиции. Действительно, логистика и проведение самого анализа биоматериала давно автоматизированные и проработанные со стороны лабораторий процессы. А вот процедура взятия мазка и последующий контроль результатов исследования на пропускных пунктах в условиях массового наплыва клиентов новая задача.

Впрочем, сам по себе мазок это минутное дело. Большую часть времени занимает регистрация клиента в базе данных лаборатории, ввод персональных данных, проведение анкетирования, заключение договора, оплата услуг. Получается, что процедура проведения ПЦР-теста на 70% представляет из себя утомительный процесс, связанный с заполнением различных документов.

Регистрация клиента в лаборатории

Первый этап автоматизации ввод персональных данных клиента и заключение договора на оказание медицинских услуг. Smart Engines уже выпустил продукт для автоматизации ввода персональных данных. Намного проще вводить паспортные данные, просто сфотографировав документ на веб-камеру или приложив его на секунду к специализированному паспортному сканеру. Банки, мобильные операторы, транспортные компании уже оценили удобство технологии распознавания документов. Кстати, даже в РЖД автоматизировали кассы на вокзалах волшебными коробочками, которые за мгновение вводят паспортные данные.

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

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

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

Контроль результатов ПЦР-теста

Второй этап автоматизации это контроль валидности выданных тестов. Нет ничего сложного, если надо проверить результаты теста у 100 человек. А если их тысячи (крупные офисы в мегаполисе) или десятки и даже сотни тысяч человек (аэропорта, ж/д вокзалы, речные и морские порты)? И каждый идет со своим индивидуальным бланком справки (как бы это смешно ни звучало, но нет единого шаблона таких справок о результатах ПЦР тестирования).

Помимо проверки непосредственно результата теста, важно следить за валидностью и подлинностью таких справок. Помните этот громкий международный скандал, когда 190 пассажиров рейса Москва Чжэнчжоу предоставили идентичные результаты серологического теста на антитела к COVID-19, что в результате привело к проблемам международного авиасообщения?

Система распознавания Smart Document Engine не только автоматически контролирует результаты в сертификатах тестирования COVID-19 для трех основных лабораторий России (Гемотест, Инвитро и Хеликс), но и возвращает все необходимые данные (как текстовые, так и графические), которые могут быть использованы для анализа валидности и подлинности таких сертификатов.

Помимо мобильного кейса, на базе Smart Document Engine можно построить полноценный роботизированный комплекс - автономный программно-аппаратный комплекс сканирования и анализа данных, совместимый с различными системами СКУД. Роботизированный комплекс способен за мгновение распознать данные из сертификата, контролировать наличие или отсутствие РНК и передавать управляющее действие в СКУД. Таким образом удастся полностью исключить человека из контроля тестов на загруженных пропускных пунктах.

Итого

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

Update. Буквально вчера была опубликована новость о том, что россиян, прибывающих из Турции и Танзании до 1 мая, а после 1 мая всех граждан, прибывающих из-за границы, обязали дважды сдать тест на COVID-19. Такие нововведения лишь подтверждают, что крайне необходима автоматизация процесса проведения ПЦР тестирования и контроля полученных результатов.

Подробнее..

Эволюция баркода

17.06.2020 12:21:27 | Автор: admin
Баркод, безусловно, относится к одному из тех изобретений человечества, которые изменили течение нашей жизни. Благодаря появлению штрихового кодирования и его последующей эволюции, многие обыденные действия не только значительно упростились и ускорились, но иногда и приобрели неожиданные формы. В процессе нашей деятельности по разработке и улучшению алгоритмов интеллектуального распознавания документов (IDR) и движка распознавания баркодов Smart BarcodeReader мы постоянно систематизируем знания в предметной области. Понимание того, как развивается технология, позволяет нам совершенствовать наши разработки, делать их более быстрыми, точными и эффективными. Сегодня мы расскажем о том, как эволюционировал (и продолжает эволюционировать) баркод от линейного черно-белого рисунка к многомерной конструкции.



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

Идея кодирования товаров появилась одновременно с идеей организации работы идеального супермаркета, разработанной студентом Гарвардской школы бизнеса Уоллесом Флинтом в начале 1930-х годов. Предложенное техническое решение предполагало, что покупатель самостоятельно формирует перечень покупок на складе, делая проколы в специальной перфокарте покупателя. На кассе эта перфокарта по задумке должна была считываться специальным устройством, товары подавались при помощи специального транспортера, а процесс обслуживания был быстрым и для покупателя, и для продавца. Главная проблема заключалась в том, что на тот период технологии и оборудование для обслуживания подобных процессов практически отсутствовали: ЭВМ, которая требовалась бы для организации считывания и обработки информации подобного класса была бы слишком громоздка и дорога.

Следующий подход к кодированию товарного ассортимента был предпринят в 1948 году, когда аспирантами-энтузиастами из Дрексельского технологического института (США) началась проработка технологии сбора аналитической информации о покупках непосредственно на кассах в супермаркетах на основании маркировки товаров. Тогда группа исследователей создала гибрид технологии оптической звуковой дорожки (optical soundtrack) и азбуки Морзе. В классической технологии оптической звуковой дорожки по краю кинопленки наносится покрытие с неравномерной плотностью. Эта неравномерность приводит к тому, что интенсивность луча проектора, проходящего через него, также изменяется. Эти колебания яркости и преобразуются в звук.

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

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

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

Этот код располагали непосредственно на борту вагона и сделали его достаточно крупным, чтобы фотоэлемент мог выхватывать и безошибочно распознавать ярко освещенный прожектором штрих-код на проходящем мимо стационарного сканера вагона. Испытания подтвердили эффективность работы распознающей системы на скорости до 100 км/ч. Это была уже совершенно работающая технология, полностью изменившая отдельно взятый процесс в целой отрасли.

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

В конце 60-х годов в США началась разработка универсальной системы нумерации товаров как средства идентификации. Система штрихового кодирования, которую начали применять в торговле, была разработана в 1972 году и получила название UPC Universal Product Code. Штрих-коды этой системы начали присваивать всем видам товаров, производимым и зарегистрированных в США и Канаде. Одноименная организация начала активную пропаганду и внедрение использования штрих-кодов в промышленность и торговлю. Первое историческое считывание штрих-кода стандарта UPC в рознице произошло в американском супермаркете в 1974 году.

С 1977 года в Западной Европе для идентификации потребительских товаров стала применяться аналогичная американской система под названием Европейский артикул (EAN European Article Numbering). Сегодня именно эта ассоциация и занимается распределением штрих-кодов для производителей товаров. Чтобы избежать дублирования номеров, штрих-коды товарам выдаются централизованно международной ассоциацией, включающей 98 организаций из 100 стран мира. Производитель может получить штрих-код для своего товара, предварительно зарегистрировавшись в этой ассоциации.

Штрих-коды семейств UPC и EAN оперируют достаточно небольшим алфавитом, позволяющим закодировать достаточно ограниченный объем информации. UPC, используемый в США, состоит из 12 символов, EAN из 13 цифр и является немного усовершенствованной модификацией кода UPC. Кодирующие символы это вертикальные полосы различной ширины и пробелы между ними. В стандартных линейных кодах зашифрована информация о стране происхождения товара, организации-изготовителе, непосредственно код товара. Для проверки корректности кода в конце размещается контрольная цифра и специальный знак, указывающий на то, что товар производится по лицензии.


Теперь посмотрим на код с точки зрения структуры и принципов кодирования. Здесь мы подробно разберем только один стандартизированный штрих-код типа UPC-A, чтобы показать: принципы кодирования, которые применяются значительно сложнее, чем кажутся на первый взгляд. Эта сложность обеспечивает безошибочность распознавания за счет минимизации риска неверного считывания.



Штрих-код типа UPC-A код разделен на 2 равные части и отображается в виде темных (штрихов) и светлых (пробелов) полос, которые кодируют 12-значный номер UPC-A. Каждая цифра это уникальный набор из 2 штрихов и 2 пробелов переменной ширины в 1, 2, 3 или 4 модуля (в данном случае минимальная дискретная ширина полосы). При этом общая ширина кодирующих полос для каждой цифры остается неизменной 7 модулей. Таким образом содержательная часть товарного кода UPC-A кодируется в 84 единицах.

Многие задавались вопросом, почему на разных штрих-кодах одинаковые цифры могут быть несколькими разными способами (некоторые даже строили на сей счет конспирологические теории). Делов в том, что алгоритм кодирования штрих-кода не совсем линейный. В правой и левой частях кода цифры кодируются неодинаково: чередование штрихов и пробелов в цифрах происходит по трем наборам последовательностей (A, B и С). В последовательности А темных модулей всегда нечетное количество, в наборах В и С четное. При этом набор В представляет собой инверсию набора а (штрихи заменены пробелами и наоборот), а набор С зеркальное отражение набора В. Знаки символа в числовых наборах А и В всегда начинаются слева со светлого модуля и заканчиваются справа темным модулем, а в числовом наборе С начинаются слева с темного модуля и заканчиваются справа светлым модулем. В левой стороне при кодировании цифр используются наборы А или В в зависимости от позиции цифры в коде, правая сторона кодируется набором C. Алгоритмы кодирования подробно прописаны в стандартах. Например, в этом.

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

Форматы штрих-кодов постоянно совершенствуются и меняются. На сегодняшний день помимо принятых в международном товарообороте стандартных Universal Product Code и European Article Numbering существует более 300 стандартов штрих-кодирования.

С 2005 года принят международный стандарт, в котором используются три основные типа кодирования информации о товарах:

  • EAN-8 (сокращённый) кодируется 8 цифр.
  • EAN-13 (полный) кодируется 13 цифр (12 значащих + 1 контрольная сумма).
  • EAN-128 позволяет кодировать любое количество букв и цифр, объединенных в регламентированные группы.

В отличие от EAN-8 и EAN-13, кодом EAN-128 (GS1-128) используется производителями, перевозчиками и торговыми компаниями для обмена данными о перевозимых грузах. В этом, более длинном коде, может содержаться расширенная информация, такая как номера накладных, индексы пунктов назначения, объемы перевозимого груза, коды товара и серийные номера изделий, сроки годности и пр.

Главное преимуществом штрих-кода это его простота, функциональность и помехозащищенность. Главный недостаток же относительно малое количество информации, которую с помощью него можно закодировать.

Эра 2-D


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

Кроме этого возникала необходимость маркировать кодами буквально все: не только, допустим, узлы агрегатов, но и отдельные детали. Поэтому возникала необходимость миниатюризировать код и повысить плотность кодируемой информации на единицу площади.

В двумерном коде, как и следует из названия, кодирование происходит не по одному направлению, а по двум. Действительно, если расположить несколько одномерных кодов в виде чередующихся фрагментов, получится простейший двумерный код типа Stacked Linear (составной линейный). Если мы упакуем модули в квадрат получится матричный баркод (Matrix).

Пример составного линейного баркода PDF417, появившийся в 1991 году и запатентованный в 1993. Код PDF417 состоит из строк, образуемых словами набором из чередующихся штрихов и пробелов (4 штриха, 4 пробела первое число из названия кода). Общая длина каждого слова 17 модулей (второе число в названии кода).

Помимо собственно содержательных слов, каждая строка состоит из старт-паттерна (крайнего левого набора, ключевых слов (индикаторов они занимают крайние позиции на строке), необходимых для коррекции ошибок, и стоп-паттерна (Впрочем, существует также и так называемый усеченный PDF417 (truncated), где исключен индикатор правой строки и уменьшен шаблон остановки до одной линии. Таким образом, усеченные PDF417 занимают меньше места, но они более восприимчивы к неправильному прочтению. Такой вариант PDF417 используют только там, где риск повреждения изображение кода минимальный). Так как все слова имеют одинаковую длину, размещенные одна под другой строки образуют колонки. В самом коде PDF417 как количество строк, так и количество столбцов может варьироваться: код может содержать от 3 до 90 строк, и иметь ширину от от 3 до 30 столбцов включительно, не считая столбцов со словами индикаторами. Подробная статья про кодирование PDF417 недавно выходила на Хабре здесь, а о возможности его ручного декодирования здесь.



Особенность кода PDF417 заключается в возможности кодировать информацию в текстовом режиме, числовом режиме и режиме данных (байт-режиме).

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

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

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

Код в матрице


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

Код Data Matrix


Код DataMatrix был изобретен компанией International Data Matrix в середине 1980-х для программы Space Shuttle, где требовалась маркирровка большого количестко деталей. Data Matrix был разработан до PDF417, а не предшествовал ему, как указывается в некоторых источниках. Важное преимущество кода его компактность и простота нанесения. В настоящее время Data Matrix описывается соответствующими стандартами ISO.



DataMatrix это двумерный штрих-код, который может хранить до 3116 цифр и до 2335 букв. Информация в баркоде Data Matrix кодируется черными и белыми квадратами (модулями) при этом минимальный линейный размер модуля 0.255 мм.

Шаблон поиска (finding pattern) в виде буквы L две сплошные линии на внешней стороне кода Data Matrix.Этот шаблон позволяет сканеру штрих-кода задать изображению правильную ориентацию и считать информацию в правильном порядке.

Второй важный шаблон, необходимый для понимания кода машиной, шаблон синхронизации (clocking pattern, clock track). Он необходим для информирования системы считывания о количестве модулей в матрице и для правильного распознавания сетки, на которой размещены модули.

Зона тишины (quiet zone) это область отделяющая границу штрих-кода от фона и других изображений. Для Data Matrix ширина зоны тишины равна линейному размеру используемого модуля. Маленькие габариты для зоны тишины позволяют минимизировать площадь нанесения Data Matrix на поверхность.

Специфика Data Matrix позволяет читать его как в прямом так и отраженном свете (то есть при использовании инвертированного изображения, при котором светлые модули становятся темными).

Еще одно преимущество Data Matrix, что от квадратные модули могут быть заменены на круглые. Это дополнительно расширяет возможности использования различных технологий нанесения, например в виде тиснения или ударной гравировки. Впрочем, эта же технология замены квадратного модуля на круглый взята на вооружения и в других разновидностях кодов, например в QR-коде.

Стандартизированный код Data Matrix сегодня рассматривается как ключевое звено идентификации и маркировки фармацевтических товаров и медицинских изделий. С 1 июля 2020 года маркировка кодами Data Matrix станет обязательной для всех лекарств, находящихся в обороте в России.

Подробный процесс создания Data Matrix описан здесь.

Код AZTEC


Баркод типа Aztec появился в 1995 году, как пишут, в результате объединения лучших практик разработки баркодов предыдущих поколений. Вид и структура кода Azteс разработана таким образом, чтобы она была одинаково удобна как для нанесения и считывания. Символы в целом квадратные на квадратной сетке с квадратным центральным прицелом из концентрических темных и светлых квадратов типа яблочка мишени (в англоязычных описаниях используется термин bulls eye).

Самый маленький символ Aztec Code имеет площадь 15 x 15 модулей, а самый большой 151 x 151. Самый маленький символ Aztec Code кодирует 13 цифровых или 12 буквенных символов, тогда как самый большой символ Aztec Code кодирует 3832 цифровых или 3067 буквенных символов.



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

QR-код


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

QR код это еще одна разновидность матричного кода. Его название происходит от английского Quick Response Быстрый Отклик. Он был создан компанией Denso-Wave в 1994 году в Японии для внутреннего рынка (отличие QR-кода от других двумерных баркодов в том, что этот код позволяет кодировать символы японского (вернее, пришедшего из китая в японию) письма кандзи. Также в QR коде может быть заложена избыточная информация, которая позволяет закодировать определенные действия для программы смартфона или сканера для считывания.

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

В таком QR-коде можно легко закодировать адрес интернет-страницы, которая будет открываться при наведении на нее мобильного телефона:



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



При этом даже наличие логотипа нашей компании, закрывающего около 10% кода, не мешает корректно распознавать всю закодированную информацию.

Ниже пример QR-кода самой большой размерности, который позволяет закодировать до 1852 символов.



Перечисленные баркоды QR-коды позволяют кодировать цифровые и текстовые данные примерно с одинаковой эффективностью. Согласно сравнению, приведенному на сайте РИТ-сервис, специализирующейся на обработке штрих-кодов, QR-код позволяет кодировать большие объёмы цифровых данных на меньшей площади при одинаковом размере модуля по сравнению с Aztec и Data Matrix кодировать большие объёмы цифровых данных. Код Data Matrix уступает QR коду при кодировании более 88 цифр, Aztec уступает QR-коду при кодировании более 170 цифр. Но по эффективности кодирования текста QR-код значительно уступает Aztec, а Data Matrix превосходит только при объёме текста большем 298 символов. Однако, при кодировании текста набранного прописными (заглавными) буквами эффективности QR-код и Aztec близки, а Data Matrix уступает QR-коду уже при кодировании 88 букв.

Что объединяет все эти коды?


Машине важно понимать, что перед ней код, где находится его начало и конец. Для этого используются зоны тишины, специальные пограничные паттерны и прицелы. Кроме этого, машине необходимо понимать, в каком формате записаны данные, то есть как производить декодирование в виде цифр, цифро-буквенного текста, или в формате данных. Машина также должна иметь возможность скорректировать ошибки, чтобы случайное выпадение нескольких пикселов изображения баркода не приводило к его полной нечитаемости. Коррекция ошибок в кодах DataMatrix, Aztec, QR осуществляется с помощью кодов Рида-Соломона, исправляющих ошибки чтения и позволяющие распознавать данные даже в сильно испорченных кодах (вплоть до 30% поверхности).

Зачем вообще нужны баркоды?


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

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

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

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

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

В чем задача и проблемы распознавания баркодов?


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

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

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

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

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

А что дальше?


Где два измерения, там 3 и 4. В середине 2006 года Японская компания Content Idea of ASIA c гордостью заявили о том, что они изобрели первый в истории 3D-код. В PM-коде (от образовано от paper memory бумажная память ) в качестве третьего измерения к двумерному QR-коду был добавлен цвет. Добавление цветной компоненты, по заявлению изобретателя Татсуи Онода, если в черно белом двумерном QR-коде можно зашифровать 3 кб информации, то в трехмерном до 720 (то есть в 240 раз больше). Вместо ссылки на изображение, используя топологию цветного 3D-кода, можно зашифровать картинку целиком, а также небольшие видео и аудио фрагменты. Технология получила патенты в Японии и Европе. Судя по всему, проект развивался до 2013 года, а к настоящему моменту заморожен или закрыт. Сайт японской компании-изобретателя не обновляется с 2013 года, а скачать приложение в официальных магазинах приложений уже невозможно. (При желании его можно скачать с некоторых зеркал в сети и на размещенных на сайте разработчика образцах посмотреть, как оно работает).



В 2010 году Microsoft пошла дальше объявила о создании новой концепции высокоплотных цветных баркодов (High Capacity Color Barcode (HCCB)), где код был представлен уже в виде той же QR-подобной матрицы, однако в качестве элементов кода выступали не черные квадратные модули, а цветные (4 или 8 цветов) треугольники, каждый из которых занимал ячейки.



Проект HCCB тоже просуществовал до 2013 года: тогда Microsoft объявила о том, что проект не будет поддерживаться и был закрыт в 2015.Недавно в сети появилась информация о том, что Apple разрабатывает новые типы кодов, которые будут доступны в будущих модификациях ОС. Речь идет о круглых баркодах, где информация кодируется в виде 4-х цветных капель размещенных по центру и по периметру круга.

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

Логично предположить, что вслед за кодами с тремя параметрами, последуют четырехмерные коды, динамически изменяющиеся во времени. С точки зрения теории это очень интересные задачи, ставящие вопрос о необходимости одновременной разработки софта, позволяющего распознавать такого рода объекты. И здесь мы подходим к концепции 4D-распознавания, о котором мы расскажем позже.

В качестве послесловия


В 2013 году появилась забавная программа для мобильников Barcode KANOJO, которая декодировала (или делала вид, что декодировала) баркод не совсем привычным способом. Вместо заложенного набора символов на экране мобильного появлялась виртуальная подруга (kanojo) персонаж аниме соответствующая просканированному коду. С ней можно было дружить, завоевывать доверие (и любовь???). Проект просуществовал достаточно недолго, персонажи не генерировались а, скорее всего, просто выбирались из некоторого набора созданных заранее с внешнего сервера данных, который сейчас недоступен.
Подробнее..

Как документ на мобильнике распознается от простого к сложному

17.09.2020 10:15:44 | Автор: admin

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

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

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

Принципы

В первую очередь очертим требования, которые мы закладывали при проектировании системы. Четыре основных принципа, лежащих в основе Smart IDReader:

1. Точность (спасибо, кэп). Даже если документ будет распознаваться на фотографиях и видео кадрах, полученных при помощи малоформатной цифровой камеры, точность распознавания должна быть достаточно высокой, чтобы обеспечить автоматизацию ввода данных (а иначе, зачем распознавать).

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

3. Автономность. Безопасность данных - превыше всего. Самый безопасный способ хранения данных - не хранить данные, самый безопасный способ передачи данных - не передавать данные. По нашему мнению, мобильная система распознавания обязана быть построена так, чтобы при распознавании никакие данные за пределы оперативной памяти конечного устройства не уходили. Следовательно, вся обработка изображений и все распознавание должно происходить непосредственно на устройстве, что накладывает дополнительные ограничения (см. п. 2) на используемые алгоритмы.

4. Масштабируемость. Наша первая система распознавания для мобильников (вот эта) поддерживала только внутренний паспорт РФ. При этом в мире существуют тысячи документов, удостоверяющих личность, и система должна быть устроена таким образом, чтобы добавить поддержку нового документа можно было быстро. Кроме того, добавление нового типа документа не должно требовать большого количества примеров, поскольку их неоткуда взять.

Трудности

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

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

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

Итак, держим в уме: всё должно быть сделано точно и быстро, только средствами мобильного устройства, при этом надо учитывать неконтролируемые условия съемки, но можно использовать несколько кадров.

Поиск документа

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

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

Для поиска шаблонов на изображении мы используем (иногда совместно) три основных подхода:

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

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

3. Наиболее общий подход, основанный на связке: особые точки + дескрипторы + RANSAC. Вначале на входном изображении производится поиск особых точек (мы используем модификацию особых точек YAPE для изображений с большим разбросом локального контраста, про эту модификацию можно почитать в этом докладе) и для каждой точки вычисляется локальный дескриптор (в нашем случае - методом RFD, модифицированным с целью ускорения). Далее в индексе известных дескрипторов запуском серии поисков ближайших соседей выявляются шаблоны-кандидаты. После этого кандидаты верифицируются при помощи метода RANSAC с учетом геометрического расположения особых точек. Этот метод используется в Smart IDReader для поиска и типизации подавляющего числа типов идентификационных документов. Подробнее про него можно почитать в этом докладе.

Поиск полей

Теперь, когда мы знаем координаты шаблона на изображении и точный тип этого шаблона (а следовательно, его соотношение сторон, настоящие физические размеры и т.п.), казалось бы, мы просто можем вырезать каждое нужное нам поле просто по его координатам? Так можно было бы делать, если бы на документах с жесткой структурой поля всегда находились в одних и тех же местах. Однако, к сожалению, из того, что на бланке документа напечатаны статические тексты (указывающие где должно быть какое-то поле) или даже пропечатаны линеечки, на которых эти поля должны находиться, еще не следует, что поля будут печататься одинаково. Как в России, так и за рубежом даже для жёстких документов качество печати документов оставляет желать лучшего и текстовые поля могут быть под углом, поверх статических текстов, поверх направляющих линеек и даже не совсем в тех местах, где нужно. Это означает, что нужно прибегать к специальным алгоритмам, предназначенным для поиска полей на найденном документе.

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

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

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

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

Обработка и распознавание полей

Теперь, когда мы наконец нашли текстовые поля, пришло время их распознавать, верно? Не совсем. Сначала задачу для распознавателя текста можно несколько облегчить, предварительно обработав изображения текстовых полей, исходя из априорных знаний о документе и о структуре распознаваемых полей. К примеру, зная, что на этом типе документа вот это конкретное поле содержится в ячеистой разграфке, или, если оно подчеркнуто, - прямые линии можно предварительно снять, используя морфологические операции. Или если мы знаем, что текстовые поля напечатаны курсивом, или если они рукописные, то предварительно можно исправить их наклон, используя поиск угла наклона букв при помощи быстрого преобразования Хафа (про это можно почитать здесь). При предварительной обработке полей зачастую рассматривается не каждое поле в отдельности, а сразу группа полей, поскольку несколько полей в рамках одной зоны, как правило, наклонены на один и тот же угол, либо написаны от руки одним и тем же почерком.

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

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

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

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

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

Использование нескольких кадров

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

В системе Smart IDReader используется подход комбинирования результатов распознавания текстовый полей с нескольких кадров, что позволяет значительно повысить точность распознавания в видеопотоке и использовать даже информацию о частичном распознавании поля (если, к примеру, на каком-то кадре поле было прикрыто бликом). О методах комбинирования результатов распознавания текстовых строк можно прочитать, например, в этой статье.

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

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

Детали, детали

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

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

Спасибо вам за внимание! Если вам интересно подробнее узнать о каких-то специфических компонентах нашей системы распознавания, пишите нам в комментариях!

Подробнее..

От хорошей работы не только волки дохнут, но и движки распознавания возникают

25.11.2020 10:14:05 | Автор: admin


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

История о том, как мы фактически перезапустили Smart Engines в продуктовом плане. И этот рассказ будет совсем не про то, как мы привлекли миллиардные инвестиции за счет копеечного ребрендинга или удачно на дистанционке ухватили государственных субсидий для поддержания бизнеса. Нет, мы по натуре не из тех, кто, как говорится, и рыбку съесть, и в пруд не лезть. Причиной многомесячных упорных работ было полное переосмысление концепции, архитектуры и назначения наших движков распознавания. Но обо всем по порядку.

Пять лет назад мы вышли на рынок с простым продуктом движок распознавания паспорта на мобильных устройствах. Функциональность была крайне проста: вы показываете движку паспорт в видеопотоке, а он возвращает в текстовом виде атрибуты документа (причем делал он это без какой-либо связи с внешними серверами, непосредственно все распознавание осуществлялось на устройстве). Никаких сверок с базами валидных паспортов, никаких запросов автоматических в МВД на предмет мошенничества, никаких других сервисов KYC. Только быстрое и качественное распознавание, которое, по нашим представлениям, должно было отчасти перевернуть цифровой мир.

Получилось. В марте 2015 года мы представили первую версию продукта Smart PassportReader, о чем трубили на всех ресурсах (чего только стоит наша статья на Хабре, где мы во всех красках рассказываем об особенностях поставленной задачи и о способах применения технологии в бизнесе). Хотя первоначально рынок вяло отреагировал на нашу инновацию, сегодня же только отдельные банки не используют эту технологию в мобильных приложениях.

С ростом количества клиентов росло и количество запросов на добавление новых функций и возможностей. Расширялась база поддерживаемых типов документов, увеличивался список поддерживаемых языков, количество используемых, раздувалась кодовая база (несмотря на то, что за прошедшие пять лет отдельные подсистемы были переписаны несколько раз с нуля, чтобы не утонуть в будущем в поддержке легаси кода). Конечно, это все сказывалось на финальном объеме SDK объем Smart IDReader в полной комплектации под iOS стал весить больше 200 Мб. Много? Да, безумно много! Однако в глаза скорее бросался огромный список возможностей ПО, чем какие-то мегабайты.

Дистанционная работа с ее размеренностью и однообразностью дала нам возможность детально проанализировать наш продукт и пообщаться с клиентами, как они используют наше SDK. Оказалось, что многие клиенты используют функционал распознавания платежных карт и штрихкодов отдельно от паспортов (фактически, в разных бизнес-кейсах и приложениях), что дало нам осознание необходимости продукта распознавания таких объектов. Назвали мы этот продукт Smart Code Engine. Само собой, мы не только выделили ограниченную функциональность из предыдущего SDK, сформировали отдельную команду мощных ребят, которые существенно расширили возможности движка в части распознавания кодифицированных объектов. А главное, сформировали ключевые требования к продукту: работать быстро, работать при любых условиях, работать точно.

В результате Smart Code Engine обеспечивает автоматическое считывание данных банковских карт, машиночитаемой зоны и баркодов в широком классе условий захвата изображений. Система устойчива к перепадам освещения, ракурсу съемки, перекосам, углу поворота, избыточному и недостаточному освещению. Система работает в реальном времени и способна на современных устройствах распознавать банковские карты и другие объекты со скоростью 25 кадров в секунду.

Smart Code Engine позволяет сканировать и распознавать банковские дебетовые и кредитные карты платежных систем Мир, Visa, Mastercard, American Express, JCB, MIR, Maestro, Unionpay и Diners Club, выпущенные различными странами мира, обеспечивая извлечение не только номера (12-19 цифр), но и срока действия и имени владельца. Поддерживается распознавание любых видов банковских карт: с нанесением данных выдавливанием (embossed), гравировкой (indent) и плоской печатью (flat printed), с горизонтальным и вертикальным расположением идентификационных данных, и тех карт, на которых данные расположены как на лицевой, так и на обратной стороне. В новом продукте пользователям стало доступно распознавание банковских карт с номером IBAN, которые широко распространены в странах Евросоюза. Модуль чтения баркодов поддерживает распознавание QR Code (включая различные дизайнерские версии), AZTEC, PDF 417, Data Matrix, CODABAR, CODE_39, CODE_93, CODE_128, EAN_8, EAN_13, ITF, UPC_A, UPC_E. Модуль распознавания данных машиночитаемых зон документов (MRZ) помимо международного стандарта ISO/ICAO (IEC 7501-1/ICAO Document 9303 ISO), учитывает локальные нормативные акты (Россия, Франция, Швейцария, Болгария, Эквадор).

Второе переосмысление относится к нашему флагманскому решению движку распознавания ID-документов. Хотя в самом начале мы позиционировали наш продукт для решения целого спектра задач, начиная от СКУД и заканчивая сложными системами искусственного интеллекта, автономно обслуживающих людей, основное применение Smart IDReader нашел в задачах удаленной идентификации и аутентификации личности. Вот лишь несколько живых кейсов: регистрация самозанятых в сервисе Мой Налог, приобретение и активация сим-карты, регистрация в мобильном клиенте Тинькофф.

Для решения таких задач требуется больше, чем просто распознавание текстовых реквизитов. Так мы создали новый продукт Smart ID Engine, который помимо распознавания данных обеспечивает многофакторную аутентификацию за счет встроенного механизма проверки лиц, анализа живости (liveness) предъявляемого документа, а также выделения признаков компрометации.

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

Такой вектор в создание комплексной системы идентификации и аутентификации личности открывает перед нами новые рубежи и новые рынки сбыта, во всех смыслах расширяя географию применимости системы. И тут мы тоже решили выстрелить: сделали распознавания арабской письменности и языков индоиранской группы. На минуточку, речь идет о 21 юрисдикциях с общим населением 500 млн человек, которые не используют надписи на латинице в национальных документах. Распознавание арабского языка внедрено для 73 типов документов, включая паспорта, ID-карты и водительские удостоверения следующих государств: Алжир, Бахрейн, Государство Палестина, Египет, Иордания, Ирак, Иран, Йемен, Катар, Коморы, Кувейт, Ливан, Ливия, Мавритания, Марокко, ОАЭ, Оман, Саудовская Аравия, Сирия, Судан, Тунис. Итого, на сегодняшний день мы поддерживаем 99 языков мира, а начинали 5 лет назад с двух русского и английского.

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

Конечно, скептики могут махнуть рукой и сказать, что тема совершенно бессмысленная и бестолковая, ибо кому может понадобиться распознавать документы на мобильники или планшете. На это у меня готов ответ. Во-первых, оптимизация алгоритмов под слабые вычислительные архитектуры позволяет сделать нам решение, работающее с непревзойденной скоростью на рабочих станциях и серверах (время обработки 1 страницы документа А4 на AMD Ryzen 7 3700X составляет порядка 2 секунд). А во-вторых, ровно такие скептические прогнозы мы уже встречали, 5 лет назад, когда выпускали продукт распознавания паспорта.

А что же дальше? Выход на западные рынки? Развитие продаж? PR и маркетинг и прочее бла-бла-бла? Конечно же нет. На Западе, как и на Востоке, мы и так есть. Продажи развиваются. PR и маркетинг уже настроен (раз вы дочитали эту статью до конца). Поэтому сосредоточимся на деле:

  • добавление новых кодифицированных объектов: распознавание отдельных текстовых строк, распознавание VIN номеров, распознавание показаний приборов учета и другие;
  • добавление новых языков и письменностей, например в Индии используется более 20 языков;
  • повышение скорости распознавания;
  • расширение списка поддерживаемых типов документов;
  • много другой интересной работы.
Подробнее..

Распознавание документов на частном примере обзор доступных платных и бесплатных решений

10.09.2020 14:18:39 | Автор: admin
Всем привет! Типичная ситуация сложилась в компании, в которой я работаю. В бухгалтерии вечный аврал, людей не хватает, все занимаются чем-то безусловно важным, но по сути бесполезным. Такое положение дел не устраивало руководство.

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

Так передо мной, как аналитиком, встала задача: найти решение для распознавания документа типичного для моей компании счет-фактуры структурировать его в имеющиеся хранилища, а также в 1С. Решение, которое будет удобным, понятным, и не влетит компании в копеечку.

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


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

Начал я с бесплатных программ:


  • glmageReader
  • Paperwork
  • VietOCR
  • CuneiForm.

В ходе распознавания нашего счета-фактуры такими программами я увидел следующее:

  • В таких программах как VietOCR, Paperwork, glmageReader можно настроить хранение отсканированных документов в определенные папки, Paperwork умеет их даже сортировать, согласно меткам.
  • В основном они хорошо справляются с текстом, а там, где текст распознан некорректно, в некоторых программах можно вручную изменить содержимое, прежде чем экспортировать файл.


image

Однако есть и проблемы:

  • Есть разница между работой с pdf сканами и png. Не всегда удается удачно конвертировать png в pdf.
  • Большинство таких программ сложно справляются с распознаванием документов табличного вида, даже самого простого формата. В результате мы получаем распознанный текст без размеченных полей.

    image
  • Иногда неточно определяется шрифт, вследствие чего при конвертации весь распознанный текст наезжает друг на друга.
  • В процессе распознавания иногда необходимо делать выравнивание по ключевым словам, с доворотами и смещением координат.
  • В некоторых программах таблица распознавалась как картинка и экспортировалась в новый документ Word тоже в качестве картинки, очень урезанной, которую даже сложно разглядеть.
  • При редактировании распознанного содержимого в некоторых программах возникали проблемы, менялся шрифт или сам текст.


image

Технология сработала достаточно хорошо, Учитывая, что программы бесплатные, описанные выше проблемы допустимы. Однако, я искал более упорядоченного решения.

Затем я исследовал распознавание в ABBYY FineReader 15 Corporate


За 7-дневный срок триала, я изучил и эту платформу.

Что отметил:

  • Когда я открыл png файл, он отлично был считан и в результате удачно конвертирован в pdf без потери качества изображения и текста.
  • Программа отлично знает, как отсканировать документ для редактирования текста. Причем в режиме редактирования файла формата png текст удается отредактировать без проблем, но иногда слетает разметка.
  • Однако то же самое я не могу сказать про редактирование файла-скана pdf. При попытке редактирования летели слои.
  • Табличный вид распознается качественно, вся структура сохраняется, меня это порадовало.
  • OCR редактор хорошо распознал мой сформированный pdf счет-фактуры. Где-то пару символов требовалось поправить вручную.

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

    image
  • Здесь можно настроить автоматическую конвертацию входящих документов, которые регулярно будут тянуться из указанной папки, по указанному расписанию.
  • Он позволяет сравнивать версии документов, даже если они в разных форматах. При большом потоке документов и правок в них, это очень удобно.

От использования этого софта были приятные впечатления. Однако, когда я обратился к ценнику системного решения ABBYY Flexicapture (а мне нужно именно системное), то выяснил, что решение, особенно кастомизированное, обходится в довольно круглую сумму, около 400 тыс. руб./мес. и выше за 10 тыс. страниц.

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

И тут я решил получше разглядеть ELMA RPA, которую я уже изучал ранее.


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

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

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

Какие виды распознавания в системе я посмотрел:

Распознавание по шаблону


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

Что отметил:
  • Этот вид распознавания работает именно со сканами формата jpg и png, pdf он пока не рассматривает. Но продукт еще молодой, думаю, все впереди.
  • Этот вид распознавания входит в бесплатную версию Community Edition
  • Удобно размечен текст по блокам, которые можно сопоставить, согласно переменным, которые мы создали в контексте робота. Таким образом вручную настроить, что именно тянем в распознавание.
  • Нашу счет-фактуру он распознал 50/50, некоторые слова подменил как посчитал нужным. :)

    image


Однако, вендор на данный кейс сообщил, что этот вид распознавания адаптирован под простые документы, с текстовой структурой или с легкими формами. И посоветовал для распознавания счета-фактуры использовать другой вид распознавания intellect lab.

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

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

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

Что отметил по поводу этого распознавания:

  • Здесь уже распознавание работает как программа сканирования документов pdf, и при этом работает и с форматами jpg и png.
  • Качество документа не влияет на эффективность распознавания. Даже документы с плохим качеством распознаются корректно.
  • Счет-фактура распозналась полностью и без подмен переменных.
  • Робот сумел получить скан с почты, распознать его и создать его экземпляр в 1С. То есть автоматически сохранил файл там, где мы ему задали, что, естественно, крайне удобно.
  • Входит в бесплатную Community Edition в виде распознавания документа в облаке. Подходит, если используем стандартные типы (СФ, УПД, АВР и др.), и, например до 100 документов в месяц или до 500 в год. (Стоит заметить, что считаем не в страницах, а в документах непосредственно.)

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

Распознавание документа в блокнот

Соответственно, эти же данные робот записывает в 1С, создавая там новый документ:

распознание документа и создание в 1С

Что удалось выяснить по ценам: Если мы, например, хотим работать масштабно именно с ilab распознаванием, то за наши 10 000 документов придется выложить:
  • примерно 180 000 руб. единовременно,
  • плюс, допустим, 400 000 руб. покупка робота с оркестратором
  • итого: 580 000 руб.

Робот бессрочный, а 10 000 документов на какое-то время хватит. Довольно выгодно получается, как минимум в том, что заплатим за все один раз.

Что понравилось в распознавании в этой платформе в целом:

  • Можно настроить получение документов по событию, а также, например из электронной почты и любых других внешних источников. У меня пока была цель настроить получение с почты.
  • Все считанные данные с документа можно спокойно записать в контекстные переменные и далее их передать в необходимые системы, приложения, сайты, ВМ и т д. И я не переписываю уже ничего руками.
  • Скорость обработки. 15 секунд и объект распознан, а остальной порядок действий это счет по минутам. Если заявиться с потоковым сканированием с большим количеством документов, думаю это не составит больших временных затрат.
  • Много качественного функционала в свободном доступе, для небольших компаний им можно вполне обойтись.


Итого:


  • Бесплатные программы справляются с задачей распознавания документов лучше, чем я предполагал, однако за счет них значительно ускорить работу с большим объемом не удастся
  • ABBYY FineReader хорошо справляется с обработкой и распознаванием документов после, однако, чтобы получить системное решение, нужны большие финансовые возможности.
  • ELMA RPA удивила по качеству распознавания документов, вариативностью, а также возможностям хранения и передачи после распознавания, но стоит учесть, что продукт молодой.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru