Мы распознаем документы и в зонах визуального контроля выделяем фото, если оно есть, функцию чтения чипа документов по NFC для телефонов на Android добавим после MWC, после распознавания это уже техническая работа.
Для расшифровки данных чипа необходимо считать или ввести руками данные содержащиеся в машиночитаемой строке (MRZ) или в зоне визуального контроля (VIZ), иначе было бы возможно дистанционно считать персональные данные. Кроме того, документов с чипом не так уж и много, например, в паспорте РФ и правах их нет.
Например, панорамирование позволяет снимать длинные чеки из магазина и получать качественное изображение, которое потом нормально распознается, а голограммы нужны в системах самообслуживания банков и других финтехов, что позволит им проверять подлинность документов на мобильных устройствах.
PS ошибки поправили, спасибо!
1) Мы не пользуемся словарями и не разбираем слова, частично потребность в этом покрывается масками * и? в ядрах ключевых слов. Это обусловлено сильной ограниченностью корпуса слов, используемых в деловых документов.
2) полностью на Ваш вопрос о «тамите» мы не ответим, было множество причин создать свой парсер. Однако легко понять, что сам парсер, описанный в статье, можно свести к проверке истинности ДНФ (или даже СДНФ) над ключевыми словами, т.е. что парсер очень прост, а причины относительного успеха его применения объясняются технологией подготовки правил, адекватных встречающимся деловым документам.
3) Ждём Вашу статью!
«0.01 — это немало, однако, это характеристика результата, основанного на описанном простом алгоритме классификации и на несовершенном OCR Tesseract. Применение более совершенного движка распознавания например, указанного Вами, позволит уменьшить эту характеристику.
У разных компиляторов различный набор настроек оптимизации и эти настройки могут быть по-разному реализованы, поэтому выставить полностью идентичный набор параметров затруднительно. Так, дефолтные значения флагов lcc предполагают довольно сильные ограничения floating-point оптимизаций. Флаг -ffast-math (отличается от -ffast-math в gcc) включает некоторые оптимизации, например, подстановку операций вместо вызова библиотечных функций. И только с флагами -ffast и -ffast-math задействуется полный набор floating-point оптимизаций, которые могут приводить к значительным изменениям результатов вычислений.
В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.
ОС Эльбрус 64-разрядная, однако можно принудительно включить для приложения 32-разрядную адресацию с помощью флага компилятора -mptr32. Обработка по 8 байт работает быстро в дефолтном, 64-разрядном режиме.
Мы использовали внешний цикл в каждом примере. Конкретно в примере 1 было сделано 10000 итераций внешнего цикла. На Core i7 компиляция выполнялась на Microsoft Visual Studio, оптимизация /О2. Одна итерация цикла заняла ~1.5 такта.
Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
По Эльбрус-4С уже опубликовано немало обзоров с результатами более или менее стандартных тестов производительности, 7-zip сжатие/распаковка, например. Для Эльбрус-2С+ есть результаты на SPEC 2000 на сайте МЦСТ. Поскольку мы занимаемся обработкой изображений и распознаванием, нам интереснее рассматривать профильные для нас задачи, которые довольно просто распараллеливаются и хорошо подходят для VLIW-архитектур.
Действительно, энергопотребление мы сравнивали только по TDP, что не совсем корректно, и было бы интересно измерить реальную потребляемую мощность. Возможно мы проведем и такой эксперимент. TurboBoost при замерах мы отключили.
Цель данного поста не сравнить производительность Эльбрус и Core i7, для этого наши примеры не очень подходят. Мы хотели показать, что несмотря на VLIW-архитектуру Эльбруса и написанный специально для нее оптимизирующий компилятор, простые методы оптимизации на нем работают также, как и на Core i7, и в этом смысле разработка программ для Эльбруса не требует дополнительных затрат на специфичную оптимизацию.
Мы не учитывали различия по памяти, поскольку у Эльбрус-4С и Core i7 не только разная скорость ОЗУ, но и разная структура кэш-памяти, алгоритмы кэширования, есть array prefetch buffer на Эльбрус. Поэтому мы использовали более наглядную и простую характеристику.
Ответы, которые мы получили для себя:
1. Процессор — рабочий.
2. Набор инструментов для разработки — имеется.
3. Поддержка и консультации — имеются.
4. Документация — есть (по ГОСТу).
5. Нужная скорость работы нашего софта — достижима (при должной оптимизации).
6. Интересно — очень!
7. Идем ли дальше — да.
Кроме того, в процессе работы над Эльбрусом мы улучшили производительность и на других платформах.
Если кратко, то вот так.
В данный момент мы перешли на следующий этап оптимизации и пока явных барьеров не видим. Вопрос времени и более глубокого изучения возможностей. Мы хотим довести время распознавания до 1 секунды и дальше уже снижать число потоков. А пока что уперлись в лето :)
1. Правильность распознавания проверяется прогоном на референтном датасете (1000 изображений паспортов).
2. Первая рабочая версия — 3 дня работы одного человека, после чего началась оптимизация производительности (3 ч.м.).
3. Для адаптации заменили порядка 100 строчек кода из ~20 мегабайт кода, все изменения обратно совместимы.
4. Оптимизированный код в том же репозитории, вызовы EML под условной компиляцией.
5. Квалификация: студенты и аспиранты, для нас — обычная.
В очень общих чертах алгоритм таков: поиск документа и наведение зон, поиск полей, распознавание полей. Наибольший эффект был достигнут на первом этапе. Про оптимизацию отдельных алгоритмов мы планируем часть 2.
PS ошибки поправили, спасибо!
2) полностью на Ваш вопрос о «тамите» мы не ответим, было множество причин создать свой парсер. Однако легко понять, что сам парсер, описанный в статье, можно свести к проверке истинности ДНФ (или даже СДНФ) над ключевыми словами, т.е. что парсер очень прост, а причины относительного успеха его применения объясняются технологией подготовки правил, адекватных встречающимся деловым документам.
3) Ждём Вашу статью!
В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.
Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
Оптимизация — опыт работы 2 и 4 года.
Тесты есть, проходят.
1. Процессор — рабочий.
2. Набор инструментов для разработки — имеется.
3. Поддержка и консультации — имеются.
4. Документация — есть (по ГОСТу).
5. Нужная скорость работы нашего софта — достижима (при должной оптимизации).
6. Интересно — очень!
7. Идем ли дальше — да.
Кроме того, в процессе работы над Эльбрусом мы улучшили производительность и на других платформах.
Если кратко, то вот так.
2. Первая рабочая версия — 3 дня работы одного человека, после чего началась оптимизация производительности (3 ч.м.).
3. Для адаптации заменили порядка 100 строчек кода из ~20 мегабайт кода, все изменения обратно совместимы.
4. Оптимизированный код в том же репозитории, вызовы EML под условной компиляцией.
5. Квалификация: студенты и аспиранты, для нас — обычная.