Microblink Capture SDK: руководство от гика, функции, интеграция, ограничения и текущий статус

↓Скачать Microblink Document Capture

Microblink Document Capture — не отдельная настольная программа и не приложение-сканер для конечного пользователя. Под этим названием в данном обзоре рассматривается коммерческий Microblink Capture SDK, также называемый BlinkID Capture SDK: набор библиотек для Android, iOS и браузера, который разработчик встраивает в собственное приложение или сайт, чтобы автоматически получить качественное изображение удостоверения личности. Его задача заканчивается на захвате и подготовке кадра: SDK обнаруживает документ в камере, оценивает условия съёмки, направляет пользователя подсказками, исправляет перспективу и возвращает обрезанное изображение вместе с исходным кадром. Полноценное распознавание полей, проверка подлинности и современный комплексный поток идентификации относятся уже к BlinkID и другим решениям Microblink.

Что представляет собой Microblink Document Capture

Разработчик Capture SDK — Microblink, компания, выпускающая программные компоненты для считывания удостоверений личности и других документов. Самостоятельный Capture SDK был представлен в июне 2023 года как отдельный слой захвата изображения перед дальнейшим извлечением данных или проверкой документа. Архитектурная идея проста: мобильный или браузерный клиент отвечает за получение пригодного кадра, а следующий компонент системы может выполнять OCR, разбор полей, сопоставление или проверку на сервере либо на устройстве.

Capture SDK рассчитан именно на удостоверения личности стандартного размера: пластиковые ID-карты, водительские удостоверения и паспорта. Компонент не привязан к перечню конкретных версий документов, потому что его основной результат — изображение, а не распознанная структура полей. Это важное отличие от BlinkID: Capture способен принять новый внешний вид документа без обновления каталога шаблонов, но само по себе такое изображение ещё не превращается в имя, дату рождения, номер документа или результат проверки подлинности.

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

Поэтому оценивать Microblink Document Capture как обычный «сканер документов» некорректно. У него нет собственного каталога файлов, редактора PDF, кнопки сохранения в папку пользователя или автономного рабочего стола. Интерфейс, который видит человек, появляется внутри приложения заказчика. Разработчик может оставить готовый Capture UX, изменить его оформление и тексты либо вообще отказаться от готового интерфейса и построить собственную камеру поверх Direct API.

Основные параметры

Параметр	Подтверждённое состояние
Официальное семейство	Microblink Capture SDK / BlinkID Capture SDK
Тип	Коммерческий SDK для встраивания захвата изображений ID-документов
Разработчик	Microblink
Основная задача	Автоматически получить качественный, обрезанный и перспективно исправленный снимок удостоверения личности
Платформы	Android, iOS и браузерная JavaScript/WebAssembly-реализация
Android	API level 21 и новее; ARMv7 и ARM64; камера с preview не ниже 1080p
iOS	iOS 13.0 и новее; Swift и Objective-C; без bitcode
Браузеры	Chrome 96+, Firefox 79+, Safari 15.2+; нужен secure context; WebView не поддерживается
Результат	Исправленное обрезанное изображение документа и исходный кадр; формат долговременного хранения задаёт интегрирующее приложение
Готовый интерфейс	Есть Capture UX с рамкой, подсказками, фонариком, onboarding и экранами помощи; доступна кастомизация
Низкоуровневый режим	Direct API для собственного интерфейса и собственной подачи кадров
Лицензирование	Коммерческая лицензия; для оценки доступна бесплатная пробная лицензия после регистрации
Текущий статус	iOS и Browser официально находятся в Maintenance Mode; Android имеет отдельную актуальную ветку релизов, включая 1.4.4

Таблица показывает главное ограничение продукта: Capture SDK — компонент конвейера, а не законченная система документооборота. Для сценария «сфотографировать удостоверение и получить качественный кадр» это осознанная специализация. Для сценария «извлечь поля, проверить документ и получить бизнес-решение» понадобится дополнительный слой.

Актуальный статус и различия платформ

Android: отдельная поддерживаемая ветка Capture

Android-репозиторий Capture SDK не содержит предупреждения Maintenance Mode, которое присутствует в iOS и Browser. В журнале релизов есть версия 1.4.4; в ней добавлен механизм пользовательской загрузки нативной библиотеки через CaptureSDK.setNativeLibraryLoader. Ранее ветка 1.4.x получила совместимость с 16 KB memory page size, обновлённую сборочную цепочку NDK, исправления CameraX и другие изменения совместимости. Это не основание считать Android вечным активно развиваемым продуктом, но и переносить на него статус iOS или браузера было бы фактической ошибкой.

Минимальная версия Android — API 21. Нативные бинарные компоненты поставляются для ARMv7 и ARM64. Если приложение включает другие нативные библиотеки, архитектуры должны совпадать: смешение несовместимых ABI приводит к ошибке загрузки нативного кода. Ещё одно жёсткое требование связано с камерой: preview должен быть не ниже 1080p. Это именно разрешение потока предпросмотра, а не максимальное разрешение видеозаписи, которое производитель телефона указывает в характеристиках.

iOS: Maintenance Mode

Официальный iOS-репозиторий прямо помечен как Maintenance Mode. Новые функции и крупные улучшения для этой ветки не планируются; Microblink оставляет существенную поддержку, критические исправления и необходимые исправления безопасности. Для существующего приложения это означает, что Capture iOS не исчезает мгновенно, однако выбор этой ветки для нового долгосрочного проекта нужно сравнивать с текущим BlinkID.

Фреймворки рассчитаны на iOS 13.0 и новее, поддерживают Swift и Objective-C и не содержат bitcode. Доступны ручное подключение XCFramework, Swift Package Manager и CocoaPods. Встроенный интерфейс строится вокруг MBICCaptureViewController и MBICCaptureSettings; результат передаётся делегату. Отдельный Direct API оставляет приложению управление камерой и экраном.

Browser: Maintenance Mode и требования веб-платформы

Браузерная версия также официально переведена в Maintenance Mode. Пакет распространяется через NPM как @microblink/capture. Полноэкранный готовый интерфейс создаётся через createCaptureUi, а безголовый вариант — через createCaptureSdk. Для низкоуровневой интеграции доступен createDirectApi.

Веб-версия требует защищённого контекста. Для многопоточной сборки сервер должен отдавать заголовки Cross-Origin-Embedder-Policy со значением require-corp и Cross-Origin-Opener-Policy со значением same-origin. Без них остаётся однопоточный режим. Ресурсы WebAssembly и Web Worker из каталога пакета должны размещаться локально с сохранением структуры. Минимальные заявленные версии — Chrome 96, Firefox 79 и Safari 15.2; WebView официально не поддерживается. Для браузерного захвата требуется камера, способная дать поток минимум 1920×1080.

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

Как устроен интерфейс Capture UX

Готовый UX построен как полноэкранный поток камеры с небольшим количеством элементов поверх preview. Он не похож на многооконный редактор: пользователь должен выполнить одну короткую задачу — показать документ камере в подходящем положении. Основные элементы Android-оверлея, прямо обозначенные в документации, — выход, управление фонариком, текст инструкций, предупреждение об освещении, пиктограмма стороны карты и рамка-reticle. Состояние рамки меняется между нейтральным, промежуточным, ошибочным и успешным.

Смысл интерфейса — давать обратную связь до того, как плохой кадр уйдёт дальше по конвейеру. Текст может просить приблизить или отдалить документ, удержать его в видимой зоне, выровнять, повернуть, уменьшить или увеличить освещение, устранить размытие либо блик. Для двухсторонней карты интерфейс меняет подсказку и показывает необходимость переворота. Это не OCR-сообщения и не проверка полей; все эти сигналы относятся к качеству захвата.

Перед камерой можно показать introduction dialog и onboarding. В Android-настройках предусмотрено управление видимостью этих экранов, а также задержкой подсказки помощи. Значение задержки по умолчанию для «Show help?» составляет 12 секунд. Тексты onboarding можно заменить ресурсами приложения; в наборе строк предусмотрены действия Skip, Back, Next и Done. Таким образом, готовый UX не вынуждает сохранять фирменную формулировку подсказок, что важно для локализации и согласования терминов с остальным продуктом.

В Android можно менять стили и ресурсы отдельных частей оверлея: иконку выхода, состояния фонарика, оформление инструкций, предупреждение об освещении, рисунки лицевой и оборотной стороны, состояния рамки, цвета, фон и типографику диалогов. Для глубокой кастомизации существует другой путь — Direct API. Он отдаёт разработчику результаты анализа кадра, а управление камерой, анимациями, экраном и жизненным циклом становится ответственностью приложения.

На iOS и в браузере принцип тот же: есть готовая оболочка и низкоуровневая интеграция. Это позволяет держать единый пользовательский сценарий на разных платформах, но конкретные API и механизм оформления различаются. Перенос настроек Android-стилей в CSS браузерной версии или в iOS-ресурсы автоматически не выполняется.

Функции и логика обработки

Автоматическое обнаружение документа

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

Оценка качества до принятия кадра

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

Перспективная коррекция и обрезка

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

Одно- и двухсторонние документы

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

Capture Filter и BlinkIdCaptureFilter

В Android ветке 1.4 появился механизм CaptureFilter, а готовый BlinkIdCaptureFilter позволяет привязать принятие стороны к тому, может ли BlinkID извлечь из неё данные. Аналогичный фильтр описан и для iOS. Такой режим уже требует отдельной интеграции BlinkID и соответствующей лицензии; он не превращает базовую лицензию Capture в лицензию на распознавание. Это критичное различие при оценке бюджета и архитектуры.

Direct API

Direct API предназначен для проектов, где готовый оверлей не подходит. На Android ядро и UX разделены на capture-core и capture-ux; AnalyzerRunner принимает поток изображений или статические изображения и возвращает обратную связь анализа. В iOS низкоуровневый режим строится вокруг соответствующего AnalyzerRunner, а в Browser доступен createDirectApi. При таком подходе Capture отвечает за анализ, а разработчик — за камеру, очереди кадров, пользовательские сообщения и восстановление состояния.

Локализация и доступность

Android SDK содержит набор готовых переводов и позволяет заменить строковые ресурсы. В выпуске 1.3.0 были добавлены, среди прочих, арабский, китайский, хорватский, чешский, нидерландский, филиппинский, французский, немецкий, иврит, венгерский, индонезийский, итальянский, малайский, португальский, румынский, сербский, словацкий, словенский, испанский, тайский и вьетнамский, а также улучшения accessibility. iOS-репозиторий указывает поддержку 23 языков и возможность редактировать локализационные ресурсы. Наличие готового русского перевода в актуальной Android-ветке отдельно в опубликованном перечне 1.3.0 не заявлено, поэтому полагаться на него без проверки конкретного пакета не следует; безопасный путь — собственные строки продукта.

Как пользоваться программой — советы гика

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

Подключить Capture SDK к Android-проекту

Цель. Добавить готовый Capture UX и его ядро в Android-приложение, не смешав неподдерживаемые архитектуры.

Подготовка. Нужен проект с Android API level не ниже 21, устройством ARMv7 или ARM64 и камерой, у которой preview достигает минимум 1080p. В репозиториях Gradle должен быть доступен Maven Central.

1. Откройте модуль приложения и убедитесь, что в списке репозиториев используется mavenCentral().
2. Добавьте зависимость com.microblink:capture-ux. Актуальная ветка release notes на момент проверки заканчивается версией 1.4.4; при обновлении проекта берите версию из текущего выпуска Capture Android.
3. Если приложение содержит другие нативные библиотеки, ограничьте упаковку ABI значениями armeabi-v7a и arm64-v8a, совпадающими с Capture.
4. Синхронизируйте Gradle и соберите приложение для физического ARM-устройства.

Важные параметры. Минимальная ОС задаётся API 21, а совместимость нативной части определяется ABI. В выпуске 1.4.4 дополнительно доступен CaptureSDK.setNativeLibraryLoader для проекта, которому нужно самостоятельно контролировать загрузку нативной библиотеки.

Проверка результата. Сборка должна завершиться без ошибок разрешения зависимости и загрузки нативной части. На устройстве приложение должно доходить до инициализации Capture без UnsatisfiedLinkError.

Типичная ошибка. Если приложение падает при старте нативного кода, первым подозреваемым является несовпадение архитектур Capture и другой C/C++-библиотеки.

Безопасный откат. Удалите зависимость Capture и добавленные ABI-настройки в том же изменении проекта, затем соберите предыдущую конфигурацию. Это возвращает приложение к состоянию до интеграции без изменения пользовательских данных.

Подключить Capture SDK к iOS-проекту

Цель. Встроить Capture в приложение iOS, где требуется сохранить существующий поток на iOS 13 и новее.

Подготовка. Нужен проект Swift или Objective-C. Следует учитывать Maintenance Mode: для нового продукта сначала сравните этот путь с текущим BlinkID, а для существующей интеграции используйте совместимую ветку Capture.

1. Возьмите из официального выпуска два фреймворка: CaptureUX.xcframework и CaptureCore.xcframework.
2. Добавьте оба XCFramework в проект Xcode. При добавлении в проект используйте вариант создания групп, а не folder references.
3. В настройках target в разделе General назначьте динамическим фреймворкам режим Embed & Sign.
4. В Linked frameworks and libraries добавьте системные libc++.tbd и libz.tbd, которые перечислены в инструкции Capture.
5. В Swift-файле импортируйте CaptureCore и CaptureUX; для Objective-C используются соответствующие заголовки этих фреймворков.

Важные параметры. Deployment target — iOS 13.0 или новее. Фреймворк не содержит bitcode, поэтому архитектура сборки не должна рассчитывать на этот устаревший механизм.

Проверка результата. Xcode должен собрать target, а классы MBICCaptureViewController и MBICCaptureSettings должны разрешаться компилятором.

Типичная ошибка. Если сборка проходит, но фреймворк не загружается на устройстве, проверьте, что оба XCFramework добавлены как embedded и подписываемые, а не только как linked.

Безопасный откат. Уберите CaptureUX и CaptureCore из target и удалите импорты, сохранив прежний экран камеры. Рабочий поток приложения останется прежним, пока вызов Capture не включён в навигацию.

Активировать лицензию до запуска захвата

Цель. Инициализировать библиотеку в допустимой конфигурации. Без действующей лицензии захват не стартует.

Подготовка. Для оценки Microblink выдаёт бесплатную пробную лицензию после регистрации в Developer Hub. Android-лицензия привязывается к application ID, браузерная — к домену. Для iOS лицензия должна соответствовать приложению и условиям, выданным Microblink.

1. Получите файл или строку лицензии для точного идентификатора тестового приложения либо домена.
2. На Android поместите файл лицензии в assets и вызовите CaptureSDK.setLicenseFile до обращения к другим классам SDK; подходящее место — инициализация Application.
3. На iOS установите строку или файл лицензии через общий объект MBICCaptureSDK до создания MBICCaptureViewController; документация рекомендует делать это на раннем этапе жизненного цикла приложения.
4. В Browser передайте значение в поле licenseKey при вызове createCaptureUi, createCaptureSdk или createDirectApi.

Важные параметры. В Android и Browser привязка идентификатора является частью проверки. Перенос строки лицензии между приложениями с другим application ID или между доменами не считается универсальной лицензией.

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

Типичная ошибка. Валидная на вид лицензия не проходит после смены package/application ID или домена. В браузере причина часто видна в консоли, поскольку лицензионные проблемы туда журналируются.

Безопасный откат. Не подставляйте другую производственную лицензию «для проверки». Верните прежний идентификатор тестовой сборки либо отключите экран Capture до получения корректной лицензии для нового окружения.

Запустить стандартный Capture UX и получить один документ

Цель. Использовать готовый интерфейс Microblink с минимальным количеством собственного кода.

Подготовка. SDK уже подключён и лицензирован, а приложение имеет разрешение на использование камеры.

1. На Android зарегистрируйте ActivityResultLauncher с контрактом MbCapture и обработчиком результата.
2. Запустите launcher с объектом CaptureSettings.
3. На iOS создайте MBICCaptureSettings, затем MBICCaptureViewController, назначьте delegate и покажите контроллер полноэкранно.
4. Конечный пользователь помещает удостоверение в рамку и исправляет положение по сообщениям Capture: выравнивает документ, меняет дистанцию, убирает блик или палец, если интерфейс показывает соответствующую проблему.
5. После принятия кадра приложение получает результат через callback Android либо delegate iOS.

Важные параметры. Готовый UX сам ведёт камеру и отображает состояние анализа. На Android успешный ответ имеет статус DOCUMENT_CAPTURED; отмена — CANCELLED. Результат анализа доступен только после успешного захвата.

Проверка результата. В объекте результата должен присутствовать analyzer result с подготовленным изображением документа. Визуально документ на rectified image должен быть обрезан по границам и не иметь перспективного трапециевидного искажения.

Типичная ошибка. Экран открывается, но захват долго не завершается. Не нажимайте принудительно «сохранить»: Capture ожидает удовлетворительного кадра. Проверяйте подсказку о свете, блике, размытии, положении и доступное разрешение camera preview.

Безопасный откат. Пользователь может закрыть оверлей кнопкой выхода; приложение должно трактовать отмену как отсутствие нового документа и сохранить прежнее состояние формы.

Настроить чувствительность контроля качества

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

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

1. Создайте AnalyzerSettings для потока Capture.
2. Для ветки, где доступны политики качества, настройте BlurPolicy, GlarePolicy и TiltPolicy. Документация определяет уровни strict, normal, relaxed и disabled.
3. При необходимости проверьте minimumDocumentDpi. В Android Direct API документация указывает значение по умолчанию 230 и механизм adjustMinimumDocumentDpi, который помогает адаптировать ограничение к размеру входного изображения.
4. Прогоните одинаковый набор условий: нормальное освещение, контролируемый блик, небольшое движение и разные дистанции.
5. Зафиксируйте выбранную политику только после того, как она даёт приемлемый баланс между отказами и качеством входных изображений для последующего обработчика.

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

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

Типичная ошибка. Слишком жёсткие пороги на старой или слабой камере создают ощущение «сканер не работает». Проблема может быть не в производительности SDK, а в том, что входные изображения систематически не удовлетворяют заданному DPI или политике качества.

Безопасный откат. Верните normal или документированные значения по умолчанию и повторите тот же тестовый набор. Не оставляйте отключённый контроль только потому, что он ускоряет демонстрацию.

Настроить onboarding, помощь, оформление и локализацию

Цель. Вписать готовый Capture UX в интерфейс приложения без переписывания анализатора.

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

1. На Android задайте видимость introduction dialog через showIntroductionDialog и onboarding через showOnboardingInfo в UX-настройках.
2. При включённой помощи настройте showHelpTooltipTimeIntervalMs, если стандартная задержка 12 000 мс не подходит интерфейсу.
3. Замените строки через CaptureOverlayStrings. Для onboarding предусмотрены ресурсы Skip, Back, Next и Done, а для камеры — отдельные сообщения о лицевой и оборотной стороне, повороте, дистанции, видимости документа, освещении, размытии и блике.
4. Задайте стиль оверлея через CaptureSettings: ресурсы выхода, фонарика, инструкций, предупреждения, пиктограмм сторон и состояний reticle.
5. На iOS изменяйте локализационные ресурсы Capture, а в Browser передавайте собственные localization strings через UiSettings и при необходимости переопределяйте CSS-переменные компонента.

Важные параметры. Отдельно проверяйте контраст и понятность error-состояния reticle. Изменение цвета не должно скрывать от пользователя сам факт, что текущий кадр не принят.

Проверка результата. В тестовой сборке каждый экран должен показывать локализованный текст, а onboarding — вести в камеру без тупикового экрана. Ошибочные условия съёмки должны иметь отличимое визуальное состояние.

Типичная ошибка. Приложение переводит общие кнопки, но оставляет англоязычные инструкции анализатора. Это происходит, когда заменён только onboarding, а набор InstructionsStrings не переопределён.

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

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

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

Подготовка. Базовый Capture уже работает. Для BlinkIdCaptureFilter дополнительно нужны BlinkID SDK и самостоятельная действующая лицензия BlinkID.

1. Запустите обычный поток Capture с документом, который содержит две стороны.
2. После принятия первой стороны не закрывайте сессию: готовый UX покажет инструкцию перевернуть документ, когда анализ определяет необходимость второй стороны.
3. Если бизнес-процесс должен отклонять стороны, не пригодные для BlinkID, подключите модуль фильтра и установите BlinkIdCaptureFilter в CaptureSettings.
4. Обработайте результат только после завершения требуемого количества сторон.

Важные параметры. CaptureFilter — точка расширения отбора результата. Сам по себе базовый Capture не обязан распознавать текст. BlinkIdCaptureFilter меняет критерий принятия через отдельный продукт, поэтому его лицензирование и размер приложения нужно учитывать отдельно.

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

Типичная ошибка. Команда подключает класс фильтра, но не добавляет BlinkID или использует только лицензию Capture. Такой проект нельзя считать корректно лицензированным для фильтра.

Безопасный откат. Уберите фильтр и вернитесь к базовому Capture, сохранив получение изображений. OCR-зависимость исчезнет, а основная функция захвата останется.

Использовать Direct API со своей камерой или статическими изображениями

Цель. Отказаться от стандартного UX, сохранив анализ качества и подготовку документа.

Подготовка. Этот режим подходит команде, которая уже умеет управлять CameraX, AVFoundation или браузерным видеопотоком, а также жизненным циклом кадров. В Android можно подключать capture-core без capture-ux.

1. Создайте AnalyzerRunner или соответствующий Direct API для платформы и задайте AnalyzerSettings.
2. Передавайте анализатору кадры своей камеры либо поддерживаемые статические входные изображения.
3. На каждом кадре считывайте обратную связь анализа и самостоятельно переводите её в подсказки интерфейса.
4. После успешного результата остановите собственную подачу кадров и заберите rectified document image вместе с нужными дополнительными данными результата.
5. Перед началом следующего документа сбросьте состояние стороны. В Android ветке 1.4 для этого предусмотрен AnalyzerRunner.resetSide в соответствующих сценариях.

Важные параметры. AnalyzerRunner рассчитан на обработку одного документа в момент времени. Direct API не предоставляет готовое управление камерой, UI, callback-обвязку и состояние экрана, которые есть в высокоуровневом варианте.

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

Типичная ошибка. Интегратор подаёт кадры слишком низкого разрешения, а AnalyzerSettings требуют более высокого DPI. В Android такой конфликт может завершить высокоуровневую сессию состоянием ERROR_ANALYZER_SETTINGS_UNSUITABLE.

Безопасный откат. Сохраните Direct API за feature flag и верните стандартный Capture UX как контрольную реализацию. Это позволяет понять, относится ли проблема к анализатору или к собственной камере и UI.

Запустить Capture SDK в браузере

Цель. Встроить захват ID-документа в обычную веб-страницу без WebView.

Подготовка. Нужен Chrome 96+, Firefox 79+ или Safari 15.2+, защищённый контекст и камера с потоком минимум 1920×1080. Лицензия должна быть выпущена для домена приложения.

1. Добавьте пакет @microblink/capture через используемый менеджер пакетов и включите стили Capture.
2. Скопируйте каталог dist/resources из пакета в публичные ресурсы приложения без переименования и изменения внутренней структуры, чтобы WebAssembly и Web Worker загружались по ожидаемым путям.
3. Для готового полноэкранного интерфейса вызовите createCaptureUi, передайте licenseKey и обработчик onCaptureResult.
4. Если нужен свой интерфейс, создайте экземпляр через createCaptureSdk и передайте HTMLVideoElement в startCameraStream.
5. Для многопоточного режима настройте на сервере Cross-Origin-Embedder-Policy=require-corp и Cross-Origin-Opener-Policy=same-origin.

Важные параметры. Без указанных cross-origin заголовков SDK способен работать только в однопоточном режиме. WebView не относится к поддерживаемым средам. В конфигурации UI можно отключать onboarding, помощь и error screen либо передавать собственные строки.

Проверка результата. DevTools не должен показывать 404 для Wasm/Worker ресурсов, камера должна получить разрешение, а callback onCaptureResult — получить результат после успешного кадра.

Типичная ошибка. На localhost демонстрация работает, а после публикации ломается. Сравните secure context, домен лицензии, пути dist/resources и заголовки сервера; эти условия часто отличаются между dev и production.

Безопасный откат. Спрячьте компонент Capture за переключателем и верните прежнюю форму загрузки изображения. Не ослабляйте политики безопасности сайта только для того, чтобы добиться запуска многопоточной сборки.

Получить и сохранить результат без потери исходного кадра

Цель. Корректно передать результат Capture следующему компоненту и не приписать SDK несуществующий формат экспорта.

Подготовка. Определите, какой слой отвечает за долговременное хранение: мобильное приложение, backend, браузер или другой SDK. Capture возвращает изображения в своих API-структурах, а формат файла выбирает ваша система.

1. Сначала проверьте статус сессии и обрабатывайте изображение только после успешного завершения.
2. Из результата возьмите перспективно исправленное обрезанное изображение документа.
3. Если по архитектуре нужен исходный контекст кадра, отдельно получите original frame и храните его только при наличии законного основания и установленного срока хранения.
4. Передайте rectified image в OCR, BlinkID, собственный backend либо энкодер файла.
5. Если приложению нужен JPEG, PNG, PDF или иной контейнер, выполняйте кодирование своим компонентом и проверяйте полученный файл уже после этой операции.

Важные параметры. В Android доступна настройка keepDpiOnTransformedDocumentImage, связанная с сохранением DPI для преобразованного изображения. Это не равнозначно встроенному PDF-экспорту.

Проверка результата. Следующий обработчик должен получать именно rectified image требуемой стороны, а не случайный полный кадр. Если создаётся файл, отдельно откройте его библиотекой, которая будет использоваться в производственном процессе.

Типичная ошибка. Команда ожидает от Capture готовый PDF и считает отсутствие такого файла неисправностью. У Capture другая граница ответственности: он возвращает изображение, а контейнер создаётся приложением. Для работы именно с PDF полезно отдельно изучить инструменты для редактирования PDF, но они решают уже следующую пользовательскую задачу, а не заменяют SDK-захват.

Безопасный откат. До внедрения нового энкодера сохраняйте прежний путь обработки результата. Не удаляйте original frame или предыдущий формат архива из производственной схемы, пока новый формат не принят всеми downstream-компонентами.

Сквозной сценарий: от камеры до готового входа для распознавания

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

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

1. Откройте экран Capture из тестовой формы приложения.
2. Покажите камере лицевую сторону стандартной ID-карты и следуйте только фактическим подсказкам о расстоянии, наклоне, освещении, блике и размытии.
3. Дождитесь успешного состояния рамки. Если документ двухсторонний, переверните его после соответствующей инструкции и завершите вторую сторону.
4. В callback или delegate убедитесь, что статус означает успешный захват и что rectified image доступен.
5. Передайте rectified image в тестовый следующий компонент. Это может быть отдельный BlinkID, собственный OCR/backend или простой модуль сохранения изображения.
6. Сравните результат следующего компонента с ожидаемой структурой. Ошибка OCR после качественного кадра диагностируется уже вне Capture; отсутствие rectified image при успешном статусе относится к обработке Capture-результата.
7. Закройте экран и повторите сессию для нового документа, проверив, что состояние предыдущей стороны не переносится.

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

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

Типичная ошибка. Вся цепочка помечается как «Capture не распознал документ», хотя Capture выполнил захват, а ошибка возникла в отдельном OCR. Разделяйте логи камеры/анализатора, статус Capture и ответ downstream-сервиса.

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

Задача → инструмент → результат → что проверить

Задача	Инструмент Capture	Результат	Что проверять
Не принять размытый кадр	Оценка резкости и BlurPolicy	Пользователь получает обратную связь до завершения захвата	Нормальный документ принимается, намеренно размытый — не проходит выбранную политику
Избежать бликов	Glare detection и GlarePolicy	Кадр с критичным отражением не становится итоговым	Подсказка соответствует реальной проблеме, а ослабление порога обосновано тестовым набором
Исправить геометрию	Document detection и rectification	Обрезанное перспективно исправленное изображение	Границы документа не обрезают содержимое, а фон не занимает большую часть результата
Снять обе стороны	Определение single-sided/double-sided	Связанный результат сторон одной сессии	После первой стороны появляется корректное продолжение, а новый документ начинается с чистого состояния
Согласовать внешний вид	Capture UX, стили, localization strings	Камера визуально встроена в приложение	Ошибочные и успешные состояния различимы, тексты не смешивают языки
Сделать полностью свой экран	Direct API / AnalyzerRunner	Анализ Capture без готового управления камерой	Приложение самостоятельно обрабатывает жизненный цикл камеры и все состояния анализа
Принимать только распознаваемые BlinkID стороны	BlinkIdCaptureFilter	Фильтрация результата через отдельный BlinkID	BlinkID действительно интегрирован и лицензирован отдельно
Передать кадр на backend	Rectified image и original frame	Изображения, пригодные для следующего слоя	Передаётся правильная сторона, соблюдены политика хранения и защита персональных данных

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

Карта форматов и совместимости

Участок	Что принимает или отдаёт Capture	Редактируемость	Потери и переносимость
Камера Android/iOS	Видеокадры камеры, обрабатываемые SDK	Параметры потока контролирует платформа и интеграция	Низкое разрешение preview ограничивает возможность успешного захвата
Direct API	Поток изображений или статические изображения в API платформы	Интегратор управляет источником кадров	Нужно самостоятельно соблюдать требования AnalyzerSettings и жизненный цикл
Успешный результат	Обрезанное перспективно исправленное изображение документа	Можно передать другому модулю и закодировать средствами приложения	Сам SDK не обещает универсальный конечный файловый контейнер
Дополнительный результат	Original frame	Доступен для собственной обработки	Содержит больше окружения и потенциально больше персонально значимой визуальной информации, поэтому хранить его без необходимости не стоит
Browser	Кадры веб-камеры; onFrameAnalysis может передавать ImageData и FrameAnalysisResult	JavaScript-приложение может строить собственную логику поверх анализа	Нужны secure context, локальные Wasm/Worker ресурсы и поддерживаемый браузер
BlinkIdCaptureFilter	Связка Capture с отдельным BlinkID	Критерий принятия можно включать в конфигурацию	Добавляются зависимость, лицензирование и требования BlinkID
Файловый архив	Не является встроенным контрактом Capture	JPEG, PNG, PDF и иные контейнеры создаёт код приложения или backend	Качество, метаданные и совместимость зависят от выбранного энкодера, а не от Capture UX

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

Требования, производительность и зависимость от оборудования

Capture содержит нативный анализ изображения, поэтому состояние камеры важнее рекламных характеристик процессора. На Android официально требуется preview минимум 1080p, на Browser — поток минимум 1920×1080. Смартфон может уметь записывать 4K-видео, но выдавать приложению более низкий preview в конкретной конфигурации камеры; именно фактический вход анализатора влияет на пригодность кадра.

Для Android также важна архитектура CPU. SDK содержит нативные библиотеки ARMv7 и ARM64. Устройство x86 или нестандартная комбинация нативных зависимостей не относится к гарантированному сценарию. Если проект использует несколько C/C++ SDK, совместимость ABI нужно рассматривать как часть сборочной архитектуры, а не как проблему пользовательского интерфейса.

Размер Android-библиотеки в документации оценён примерно в 2,6 МБ увеличения APK, а отдельные архитектурные бинарные пакеты — примерно 2,4 МБ для ARMv7 и 2,5 МБ для ARM64. Для iOS документация указывает около 2,1 МБ в сжатом и 3,1 МБ в распакованном виде. Эти цифры описывают собственный пакет Capture, но не суммарный размер приложения с BlinkID, аналитикой, сетевым стеком и другими SDK.

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

При проблемах камеры стоит сначала исключить аппаратные ограничения. Материал GeekHow о веб-камерах для компьютера полезен как справка по классу устройств, однако для Capture Browser всё равно решающим остаётся фактический поток не ниже заявленного SDK минимума, а не название модели камеры.

Интернет, безопасность и приватность

Capture предназначен для клиентского захвата и выполняет анализ кадров внутри SDK на устройстве или в браузере. Это снижает необходимость отправлять каждый промежуточный кадр на удалённый сервер только ради наведения камеры. Однако из этого не следует, что вся система автоматически работает офлайн: лицензирование отдельных конфигураций может требовать сетевой проверки, а дальнейший OCR или backend заказчика способен быть облачным.

В Android release notes отдельно появилось разрешение INTERNET для лицензий, которые проверяются онлайн. Высокоуровневый Android-результат различает ERROR_LICENCE_CHECK, когда онлайн-активация нужна, но не состоялась. Поэтому архитектура приложения должна отделять «камера и анализ доступны локально» от «вся продуктовая цепочка независима от сети». Это разные утверждения.

Browser жёстко зависит от веб-модели безопасности. Камера работает только в secure context, а многопоточность требует COEP/COOP-заголовков. Эти заголовки влияют на изоляцию контекста страницы, поэтому менять их следует с учётом всех сторонних скриптов и ресурсов сайта. Попытка обойти ограничение через неподдерживаемый WebView ухудшает предсказуемость и не соответствует опубликованным требованиям Capture.

Документы удостоверяют личность и содержат персональные данные. Capture может вернуть как выровненный документ, так и исходный кадр, поэтому разработчик должен сам определить минимально необходимый набор хранимых изображений, доступ к ним, срок хранения, шифрование при передаче и основания обработки. SDK не превращает изображение в «безопасный файл» автоматически. Чем меньше ненужных кадров записывается в логи, crash reports и общедоступные каталоги, тем меньше поверхность утечки.

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

Отдельная проблема — downstream-обработка. Если rectified image отправляется в облачный OCR или сервис проверки, правила хранения и география обработки определяются уже этим сервисом и договором с ним. Локальная работа Capture не делает следующий сервер локальным. В архитектурной документации стоит явно отметить границу, где изображение покидает устройство.

Цена, лицензирование и пробный режим

Capture SDK — коммерческий продукт. Для запуска требуется действующая лицензия; бесплатная оценочная лицензия выдаётся после регистрации в Microblink Developer Hub. Android-лицензия привязана к application ID, браузерная — к домену. Открытая документация самостоятельного Capture не публикует действующую фиксированную цену или таблицу тарифов, поэтому числовую стоимость в обзор включать нельзя.

У пробной лицензии Capture в открытых репозиториях подтверждён сам факт бесплатной оценки, но не актуальная единая длительность для всех платформ. Это важнее, чем переносить срок пробного периода с современного BlinkID или другого продукта Microblink. Для бюджета production-проекта нужны коммерческие условия, выданные именно для используемого SDK и нужных идентификаторов приложений или доменов.

Отдельные функции способны изменить стоимость владения даже без публичной цены Capture. BlinkIdCaptureFilter требует отдельного BlinkID SDK и соответствующей лицензии. Свой Direct API увеличивает объём разработки и тестирования, потому что команда берёт на себя камеру и UX. Browser требует настройки инфраструктуры и совместимости cross-origin изоляции. Эти затраты не являются «скрытыми платными функциями» Microblink, но влияют на реальную цену интеграции.

Что перестанет работать первым

Зависимость	Что ломается	Что остаётся	Практический вывод
Недействительная или не подходящая идентификатору лицензия	Инициализация Capture и возможность сканирования	Остальная логика приложения, не зависящая от Capture	Лицензионное состояние нужно диагностировать отдельно от камеры
Нет сети при лицензии, требующей онлайн-проверки	Проверка лицензии и запуск соответствующей сессии	Локальные части приложения, которым не нужна сеть	Не обещать полный offline без проверки типа production-лицензии
Camera preview ниже минимума	Надёжный анализ и успешный захват	Само приложение и другие экраны	Проверять реальный preview, а не рекламное разрешение камеры
Несовместимый ABI Android	Загрузка нативного Capture-кода	Java/Kotlin-части, не обращающиеся к сломанной библиотеке	Согласовать ARMv7/ARM64 со всеми нативными зависимостями
Browser без secure context	Работа камеры и поддерживаемый сценарий SDK	Обычная статическая часть сайта	HTTPS и политика браузера — часть системных требований
Нет COEP/COOP в Browser	Многопоточный режим	Однопоточный режим при остальных выполненных условиях	Не ослаблять безопасность; корректно настроить сервер
Не загружены dist/resources	WebAssembly/Worker и инициализация Browser SDK	HTML/CSS приложения	Пути ресурсов надо проверять в Network до отладки алгоритма
Отключён downstream OCR	Извлечение полей после успешного кадра	Сам Capture продолжает возвращать изображения	Не путать успех захвата с успехом распознавания

Эта таблица показывает, почему сообщение «сканер не работает» слишком общее. Для Capture полезно раздельно наблюдать лицензию, камеру, анализатор, UI и следующий сервис. Тогда ошибка быстрее попадает к нужной команде.

Плюсы

• Специализация на качестве ID-кадра: обнаружение документа, контроль размытия, блика, света, наклона и перекрытия пальцами работают до передачи изображения дальше.
• SDK возвращает перспективно исправленное обрезанное изображение и исходный кадр, что даёт приложению свободу строить собственный downstream-конвейер.
• Готовый Capture UX уже содержит камеру, рамку, фонарик, инструкции, onboarding и помощь; для большинства обычных потоков не требуется создавать весь экран с нуля.
• Direct API позволяет отказаться от готового интерфейса и использовать анализ Capture с собственной камерой или подачей изображений.
• Поддерживаются одно- и двухсторонние удостоверения с продолжением сессии на оборотной стороне.
• Android, iOS и Browser имеют сходную концепцию результата, поэтому одна бизнес-архитектура может обслуживать несколько клиентских платформ.
• Capture не ограничен каталогом конкретных версий удостоверений для самого этапа получения изображения, поскольку базовая задача не зависит от распознавания полей.
• Интерфейс и строки можно адаптировать под продукт, а не показывать пользователю неизменяемый экран стороннего приложения.

Минусы

• iOS и Browser официально находятся в Maintenance Mode и не получают новых функций или крупных улучшений, что снижает привлекательность этих веток для нового многолетнего проекта.
• Capture сам по себе не является OCR или системой проверки подлинности: для структурированных полей и более современного ID-процесса нужен отдельный компонент.
• Производственная цена не опубликована в виде открытой таблицы, поэтому бюджет нельзя оценить до получения коммерческих условий.
• BlinkIdCaptureFilter требует отдельного BlinkID и его лицензирования, а не входит в базовый Capture как бесплатное распознавание.
• Есть аппаратные ограничения: Android требует camera preview не ниже 1080p, Browser — не ниже 1920×1080; Android нативно рассчитан на ARMv7 и ARM64.
• Браузерная интеграция требует secure context, локального размещения Wasm/Worker ресурсов и, для многопоточности, корректной cross-origin изоляции.
• Готового пользовательского экспорта в PDF или файлового менеджера нет: кодирование и хранение результата — ответственность приложения.
• При Direct API команда получает больше контроля, но одновременно берёт на себя камеру, UI, состояние сессии и обработку обратной связи.

Кому подойдёт

• Команде с существующим мобильным приложением, которой нужен отдельный клиентский слой получения качественных изображений ID перед собственным серверным распознаванием.
• Проекту, где важно сохранить полный контроль над downstream-обработкой и не привязывать сам этап захвата к каталогу шаблонов распознавания.
• Существующим пользователям Capture iOS или Browser, которым нужна поддерживаемая стабильная ветка без обязательной немедленной миграции, при условии что Maintenance Mode устраивает дорожную карту.
• Android-проекту на ARM-устройствах, где готовый Capture UX закрывает камеру и проверку качества, а результат обрабатывается собственной системой.
• Команде с нестандартным интерфейсом камеры, готовой использовать Direct API и самостоятельно реализовать весь пользовательский слой.

Кому не подойдёт

• Пользователю, который ищет готовое приложение «открыть — отсканировать — сохранить PDF»: Capture SDK требует разработки и встраивания.
• Проекту, которому сразу нужны распознанные поля, проверка подлинности, современная поддержка большого каталога документов и единый актуально развиваемый продукт; здесь логичнее сравнивать текущий BlinkID и конкурирующие ID SDK.
• Новому браузерному или iOS-продукту, для которого обязательны постоянные новые функции именно в Capture: официальная дорожная карта этих веток ограничена maintenance-поддержкой.
• Android-среде без ARMv7/ARM64 или устройствам, где камера не выдаёт требуемый preview.
• Веб-приложению, которое запускается только во встроенном WebView: такая среда официально не поддерживается Browser Capture.
• Системе, которая не готова управлять персональными изображениями документов, сроками хранения и разграничением доступа. SDK решает технический захват, но не заменяет политику защиты данных.

Сравнение с другими аналогами

Прямого аналога «один в один» у Capture немного, потому что он намеренно отделяет получение изображения от распознавания. Поэтому сравнение полезнее строить по рабочему результату: нужен только качественный кадр, универсальный скан документа или сразу структурированные данные удостоверения. Ниже все варианты сопоставлены по одинаковым критериям.

Решение	Задача	Платформы	Порог освоения	Форматы и результат	Автоматизация	Модель оплаты	Ограничения	Подходящий сценарий
Microblink Capture SDK	Получить качественное изображение ID без обязательного распознавания полей	Android, iOS, Browser	Средний: готовый UX упрощает интеграцию, Direct API требует собственной камеры	Rectified image и original frame; файловый контейнер задаёт приложение	Автозахват, качество кадра, определение сторон, подсказки	Коммерческая лицензия; бесплатная оценочная лицензия; цена production публично не зафиксирована	iOS и Browser в Maintenance Mode; нет собственного OCR и PDF-архива	Существующий конвейер, где распознавание или проверка уже выполняются другим компонентом
Microblink BlinkID	Захватить ID и получить структурированные данные; в актуальном семействе доступны более широкие сценарии ID scanning и verification	Нативные мобильные SDK, web, а также серверные варианты в текущей продуктовой линейке	Средний: готовый UX есть, но модель данных и настройки распознавания шире Capture	Структурированные поля и изображения документа, а не только подготовленный кадр	Захват, распознавание, автоматическое определение документа и обработка полей	Коммерческий продукт с оценочным доступом; production-условия предоставляются Microblink	Более широкий SDK увеличивает интеграционную поверхность; современная ветка имеет более высокие минимальные требования ОС, чем старый Capture	Новый проект, которому нужен не только снимок, но и актуально развиваемое извлечение данных
Scanbot Document Scanner SDK	Сканировать документы общего назначения, а не только удостоверения	iOS, Android, Web, Flutter, React Native, .NET MAUI и другие поддерживаемые обёртки	Ниже для типового сканирования: готовые компоненты, но специализированные data-capture модули требуют отдельной настройки	JPG, PDF, TIFF и PNG; доступны обрезка, выравнивание и фильтры	Автозахват, автоматическая обрезка, Document Quality Analyzer, фильтры	Фиксированная годовая лицензия по числу приложений/доменов и набору функций; без лимита сканов и пользователей; доступна 7-дневная trial-лицензия для development/staging	Для извлечения ID-полей нужны соответствующие модули, а не один Document Scanner	Приложение, которому важны готовые файловые форматы и сканирование разных бумажных документов
Scandit ID Scanner SDK	Считывать данные физического и цифрового ID и при выбранной редакции выполнять валидацию	Web и native; поддерживаются основные кроссплатформенные фреймворки	Средний: есть готовые компоненты и полностью настраиваемый SDK	Структурированные данные из MRZ, PDF417, VIZ и других поддерживаемых источников ID	On-device scanning по умолчанию, ID Scan; отдельная ID Validate для проверки	Фиксированная годовая или usage-based модель; Core, Standard, Advanced и ID Validate; доступна 30-дневная пробная версия SDK	Это уже распознающий ID SDK, а не нейтральный слой получения изображения; функции зависят от редакции	Frontline- или web-процесс, где нужны поля удостоверения и управляемая коммерческая модель
Regula Document Reader SDK	Считывать и проверять удостоверения, включая OCR, MRZ, barcode, RFID и проверки подлинности в зависимости от компонентов	Mobile SDK для iOS/Android/cross-platform, Web Service, Web Components и Desktop	Выше: много модулей, вариантов развёртывания и лицензионных схем	Структурированные результаты распознавания, изображения и результаты проверок; набор зависит от компонента	Захват, OCR, MRZ/barcode, quality assessment, authenticity checks, RFID при выбранной конфигурации	Mobile, Online, Software и Hardware licensing; online-модель включает варианты для доменов и сервисов	Сложнее архитектура и лицензирование; конкретный функционал зависит от приобретённых компонентов	Регулируемый или корпоративный процесс, где нужен широкий набор проверок документа и разные способы развёртывания

Для чистого capture-пайплайна Microblink Capture остаётся концептуально простым: он не диктует, как распознавать и где хранить данные. Но при новом проекте это преимущество нужно сопоставить с Maintenance Mode двух платформ. BlinkID логичнее, если downstream ещё не построен; Scanbot сильнее в универсальном документ-сканировании и готовых файловых форматах; Scandit и Regula закрывают более широкий слой ID data capture и verification.

Типичные проблемы и диагностика

Capture не стартует и возвращает ошибку лицензии

Симптом. Экран захвата не переходит к рабочей сессии; Android может вернуть ERROR_LICENCE_CHECK, Browser пишет лицензионную причину в console.

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

Диагностика. Сопоставьте идентификатор текущей сборки или домен с параметрами выданной лицензии и отделите лицензионную ошибку от ошибки камеры. В Browser используйте точный текст console, а на Android — статус результата.

Исправление. Установите действующую лицензию для фактического идентификатора до создания Capture-компонентов; при онлайн-проверке восстановите требуемое сетевое соединение.

Проверка результата. SDK проходит лицензионную стадию и переходит к инициализации анализатора/камеры без прежнего статуса.

Android падает с UnsatisfiedLinkError

Симптом. Java/Kotlin-код компилируется, но приложение падает при загрузке нативной части Capture.

Возможная подтверждённая причина. Capture поставляется для ARMv7 и ARM64, а другая нативная зависимость приложения упакована в несовместимом наборе ABI.

Диагностика. Сравните ABI всех .so-библиотек в итоговом APK/AAB и архитектуру тестового устройства. Ошибка на этапе загрузки нативной библиотеки не связана с качеством документа.

Исправление. Приведите нативные зависимости к общему поддерживаемому ARM-набору и ограничьте abiFilters теми архитектурами, которые реально присутствуют во всех необходимых SDK.

Проверка результата. Приложение проходит загрузку CaptureSDK и открывает экран без UnsatisfiedLinkError.

Сессия завершается ERROR_ANALYZER_SETTINGS_UNSUITABLE

Симптом. Capture отменяет обработку ещё до нормального пользовательского захвата и возвращает состояние неподходящих настроек анализатора.

Возможная подтверждённая причина. Разрешение входного изображения слишком мало для требований AnalyzerSettings, например заданного минимального DPI документа.

Диагностика. Сравните фактическое разрешение input frame с настройками minimumDocumentDpi и размером документа в кадре. На Android также учитывайте минимум 1080p для camera preview.

Исправление. Подайте поток достаточного разрешения либо верните документированные параметры качества; в Direct API используйте предусмотренный механизм адаптации minimum document DPI там, где он подходит сценарию.

Проверка результата. Анализатор принимает конфигурацию и начинает выдавать обычную обратную связь кадра вместо ошибки settings unsuitable.

Документ виден, но автоматический захват не завершается

Симптом. Рамка остаётся в процессе или ошибочном состоянии, хотя карта находится перед камерой.

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

Диагностика. Смотрите конкретную инструкцию Capture, а в Direct API — результат анализа кадра. Не заменяйте это предположением о «медленном телефоне» без данных.

Исправление. Устраните именно отмеченное условие или скорректируйте политику качества после воспроизводимого теста. Общие приёмы работы с камерой телефона можно сверить с материалом GeekHow о том, как лучше фотографировать на камеру iPhone, но критерий принятия кадра задаёт сам Capture.

Проверка результата. При нормальных условиях reticle переходит в success, а результат содержит rectified image.

Новый документ начинает обработку не с той стороны

Симптом. В собственном Direct API следующая сессия ведёт себя так, будто предыдущий двухсторонний документ ещё не завершён.

Возможная подтверждённая причина. AnalyzerRunner хранит состояние текущего документа; в Android 1.4 для управления стороной добавлен resetSide.

Диагностика. Сравните поведение стандартного Capture UX и собственной Direct API-обвязки. Если проблема возникает только в собственном потоке после повторного старта, проверяйте сброс состояния стороны.

Исправление. Завершайте жизненный цикл предыдущего документа и используйте предусмотренный API сброса перед новой независимой сессией.

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

Browser загружает страницу, но Capture не инициализируется из-за ресурсов

Симптом. UI не доходит до камеры, а Network показывает 404 или ошибки загрузки WebAssembly/Web Worker.

Возможная подтверждённая причина. Каталог @microblink/capture/dist/resources не размещён на сервере, переименован или изменена его внутренняя структура.

Диагностика. Откройте Network и проверьте каждый ресурс Capture до анализа JavaScript callback. Ошибка загрузки Wasm не является ошибкой документа.

Исправление. Размещайте resources локально в публичной части приложения без изменения ожидаемых имён и путей.

Проверка результата. Все Wasm/Worker-файлы отвечают успешно, после чего createCaptureUi или createCaptureSdk проходит инициализацию.

Browser работает только в однопоточном режиме

Симптом. SDK запускается, но threaded-вариант недоступен.

Возможная подтверждённая причина. Сервер не отдаёт COEP require-corp и COOP same-origin, необходимые для соответствующей изоляции.

Диагностика. Проверьте response headers основной страницы и совместимость сторонних ресурсов с cross-origin isolation.

Исправление. Настройте корректные COEP/COOP на уровне сервера и исправьте несовместимые подключения ресурсов; не подменяйте решение отключением браузерных механизмов безопасности.

Проверка результата. Контекст страницы становится cross-origin isolated и SDK получает возможность использовать threaded-сборку.

Capture Browser не получает камеру во встроенном WebView

Симптом. Та же логика работает в поддерживаемом браузере, но не запускается внутри встроенного web-контейнера приложения.

Возможная подтверждённая причина. Официальная Browser-документация не поддерживает WebView, связывая это с требованиями secure context.

Диагностика. Воспроизведите страницу в заявленной версии Chrome, Firefox или Safari с HTTPS. Если там Capture работает, не переносите неисправность на анализатор.

Исправление. Используйте нативный Capture SDK внутри мобильного приложения либо поддерживаемый обычный браузерный поток вместо WebView.

Проверка результата. Камера и Capture стартуют в официально поддерживаемой среде.

iOS вызывает обработчик результата дважды на старой сборке

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

Возможная подтверждённая причина. В changelog iOS версии 1.4.3 отдельно зафиксировано исправление редкого дублирования callback.

Диагностика. Зафиксируйте версию Capture iOS и счётчик вызовов delegate без повторного открытия экрана.

Исправление. Перейдите на maintenance-выпуск, где исправление присутствует, после проверки совместимости приложения. Дополнительно downstream должен иметь защиту от повторной обработки одного бизнес-события.

Проверка результата. Одна завершённая сессия вызывает ожидаемую обработку результата один раз.

BlinkIdCaptureFilter не даёт ожидаемого результата

Симптом. Базовый Capture без фильтра принимает изображение, а после включения BlinkIdCaptureFilter поток перестаёт принимать нужную сторону или возникают проблемы отдельной зависимости.

Возможная подтверждённая причина. Фильтр использует отдельный BlinkID SDK и требует отдельной действующей лицензии BlinkID; это не встроенный режим базовой Capture-лицензии.

Диагностика. Сначала подтвердите работу Capture без фильтра, затем отдельно инициализацию BlinkID и только после этого связку фильтра.

Исправление. Добавьте совместимую BlinkID-зависимость и корректную лицензию либо отключите фильтр, если downstream-распознавание не должно влиять на принятие кадра.

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

FAQ

Capture SDK распознаёт имя, дату рождения и номер документа?

Базовая задача Capture — получить качественное изображение. Структурированные поля относятся к BlinkID или другому downstream-распознавателю. Наличие BlinkIdCaptureFilter означает интеграцию отдельного BlinkID, а не скрытый OCR внутри базового Capture.

Можно ли использовать Capture как обычный сканер листов A4 и чеков?

Продукт проектировался для стандартных удостоверений личности, водительских удостоверений и паспортов. Для универсальных бумажных документов рациональнее SDK, который прямо заявляет document scanning, многостраничный поток и нужные файловые форматы, например специализированный Document Scanner.

Нужно ли обновлять Capture при появлении нового дизайна удостоверения?

Для самого захвата стандартного ID Capture не привязан к каталогу конкретных версий документа. Но downstream-распознавание или проверка может зависеть от поддержки новой версии. Поэтому обновление Capture и обновление OCR — два разных вопроса.

Есть ли у Capture встроенная кнопка «Сохранить в PDF»?

Нет подтверждённого файлового экспорта такого типа. SDK возвращает подготовленное изображение и исходный кадр через API; PDF, JPEG, PNG или другой контейнер создаётся интегрирующим приложением или backend.

Обязательно ли хранить original frame?

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

Нужен ли интернет во время каждого захвата?

Нельзя дать одно универсальное «да» или «нет» для всей системы. Анализ изображения выполняется SDK на клиенте, но отдельные лицензии могут проверяться онлайн, а downstream-сервис может быть облачным. Офлайн-режим нужно подтверждать для конкретной лицензии и всей цепочки, а не только для камеры.

Достаточно ли камеры, которая умеет записывать 4K-видео?

Сам по себе режим записи 4K ничего не гарантирует. Capture опирается на поток preview: Android требует минимум 1080p, Browser — минимум 1920×1080. Нужно проверять разрешение, которое приложение реально получает в выбранной конфигурации.

Можно ли сделать русский интерфейс, даже если готовый перевод не подходит?

Да, архитектура Capture позволяет заменять строки интерфейса. Android предоставляет CaptureOverlayStrings и отдельные ресурсы инструкций/onboarding, iOS — редактируемые локализационные ресурсы, Browser — собственные localization strings. Поэтому продуктовую терминологию можно задать самостоятельно, не полагаясь на конкретный встроенный перевод.

Maintenance Mode означает, что iOS и Browser больше нельзя использовать?

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

Почему Android и iOS нельзя считать одной и той же веткой по статусу?

Потому что официальные репозитории сообщают разное. iOS и Browser имеют явное предупреждение Maintenance Mode. В Android README такого предупреждения нет, а release notes содержат более свежую 1.4.4. Корректный обзор обязан сохранять это различие вместо общего утверждения «весь Capture закрыт».

Вывод

Microblink Capture SDK имеет смысл там, где архитектуре нужен именно контролируемый слой получения ID-изображения. Он снимает с приложения задачу анализа бликов, резкости, света, наклона, положения и сторон документа, возвращает исправленный кадр и при этом не заставляет использовать конкретный OCR или сервер.

Для существующего Android-проекта Capture остаётся технически понятным компонентом с отдельной веткой релизов и низким минимальным API 21. Для существующего iOS или Browser-проекта главный фактор — Maintenance Mode: стабильность и критические исправления сохраняются, но развитие функций не является частью этой дорожной карты.

Для нового продукта, которому нужны структурированные поля и современное развитие ID scanning, разумнее сначала сравнить Capture с BlinkID, Scandit и Regula. Если задача вообще не ограничена удостоверениями и требуется готовый PDF/JPG/TIFF/PNG, более естественным классом решения будет универсальный Document Scanner SDK, например Scanbot.

Главный критерий выбора здесь — не количество экранов и не рекламная скорость. Нужно решить, где проходит граница ответственности: только качественный кадр, кадр плюс распознавание или полный процесс проверки. Capture наиболее логичен в первом варианте. Как только проект ожидает от него OCR, архив PDF или проверку подлинности, он начинает решать задачу, для которой этот SDK не предназначен.