Обработка изображений *

Как вы себе представляете работу OCR? Страничка сканируется, программа находит области с буквами, распознает их и выдает текст. Старый добрый Tesseract так и пашет. А вот новый baidu/Unlimited-OCR делает финт ушами: он вообще не ищет буквы. Он берет всю страницу как картинку, жмет ее в горстку визуальных токенов и скармливает языковой модели, которая разворачивает их обратно в структурированный текст. Звучит как извращение, но… работает.

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

Задача звучит безобидно: «нам нужно на бэкенде превращать .docx в .html (а иногда .html в .pdf)». В тикете это одна строчка. На практике конвертация офисных документов — одна из тех тем, где красивый прототип собирается за час, а потом полгода латается по краям: то таблица разъехалась, то картинки пропали, то сервис лёг под нагрузкой, то .doc из 2007-го отказывается открываться.

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

Всем привет, меня зовут Антон, я работаю в Сбере разработчиком Java, в продукте GigaIDE. В этой статье мы перепишем нейронную сеть c Phyton’а на Java, которая распознаёт рукописные цифры MNIST. Попробуем распознавать свои цифры, рисуя их мышкой, сделаем обратный запрос в сеть и заглянем в ее «мозги», а в конце сделаем выводы.

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

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

Фото островного курорта. Ни EXIF, ни GPS, ни модели камеры – ничего. Нужно назвать курорт, координаты и сторону света, куда смотрела камера. Пытаться ответить на эти вопросы через google lens – значит упустить возможность повеселиться. Поэтому я взялся за задачу с помощью математики и программирования.

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

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

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

В первой статье я проверил одно изображение через сторонний сервис и сделал из этого слишком широкий вывод. В комментариях предложили более нормальный набор тестов: JPEG-сжатие, resize, crop, blur, скриншот, повторную генерацию и анализ частотной области. Там же мне скинули reverse engineering SynthID. Так что здесь разбираемся уже не с одним сервисом, а с самой технологией.

Как при автоматической проверке документов отличить оригинал от цветной ксерокопии или даже муляжа? Один из надежных признаков подлинности – наличие оптически-переменных защитных элементов (OVD, Optical Variable Device), например голограмм. Их внешний вид меняется при изменении угла обзора и положения источника света.

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

Ещё недавно у фальшивой личности обязательно был настоящий владелец.

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

Человек мог не знать, что от его имени берут кредит, но он существовал.

Привет, Хабр! Мы Михаил Никитин и Карина Саркисян из команды Tevian. На всякий случай уточним: мы настоящие. А вот с героями этой статьи не всё так однозначно..

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

Этот значок на компьютере моего коллеги выглядит лучше

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

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

Если прищуриться или отойти подальше, то изображение из Chrome выглядит толще. Это немного странно, но если заменить картинку на SVG, то проблема исчезнет. Однако мне всё равно стало любопытно: почему она вообще так рендерится?

Я провёл исследование и обнаружил в Chrome изящную оптимизацию, используемую для рендеринга JPEG в мелком масштабе.

Если нет времени читать всё, то вкратце: в октябре 2025 года отрасль OCR‑моделей для распознавания бухгалтерских документов пережила настоящий взрыв качества их работы. Благодаря этому нам удалось увеличить точность и производительность наших моделей в продуктах ИАД и Сайбокс:

- Сократили длительность обработки счёта с 3–4 минут до 30 секунд с помощью замены тяжёлой Qwen2.5-VL-72B на оптимизированную nanonets‑ocr2-3b.

- На 70% уменьшили объём проверок вручную, что особенно полезно для инструмента по сравнению документов (модель перестала добавлять мусор, не выдумывает числа и не искажает структуру).

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

- Таблицы теперь распознаются как HTML — за 1 секунду. Раньше приходилось гонять результат OCR через вторую LLM‑модель, чтобы распарсить таблицы.

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

Статья состоит из двух частей: первая про бизнес, вторая про технические подробности реализации и исследования.

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

В данной статье расскажем о нашем опыте определения типов микросхем на рентгеновских снимках моделью YOLO

Fisheye-камера позволяет роботу увидеть почти всё помещение одним кадром. Но за широкий обзор приходится платить: на WideDepth при увеличении угла обзора (FOV) со 120° до 195° ошибка некоторых SOTA-моделей монокулярной оценки глубины увеличивается более чем вдвое. Без точной эталонной разметки трудно понять, что именно подвело модель — геометрия камеры, отличие новых данных от обучающей выборки или погрешность самой разметки.

Чтобы разделить эти факторы, мы создали WideDepth — бенчмарк для оценки глубины по fisheye-изображениям. Он позволяет проверять модели при разных углах обзора, стереобазах и ориентациях камер.

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

Цель видна только через камеру, детектор отдает рамку, дальномера нет. В какой-то момент цель уходит из кадра на три четверти секунды, и ее надо продолжать вести вслепую. Классический фильтр Калмана в этой ситуации теряет цель в 84% эпизодов. Наш трекер теряет ее в 18% и возвращает в центр кадра в 80%.

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

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

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

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

Стандартное деление на 255

pixels = img / 255.0
result = process(pixels)
output = np.trunc(result * 255 + 0.5)

Альтернативное деление на 256

pixels = (img + 0.5) / 256.0
result = process(pixels)
output = np.trunc(result * 256)

Я предполагаю, что в обоих случаях выходные значения ограничиваются перед окончательным преобразованием типов:

# Ограничение и преобразование в 8 бит
output_8bit = output.clip(0, 255).astype(np.uint8)

В стандартном случае целочисленный 0 соответствует 0.0, а 255 соответствует 1.0. Это работает абсолютно нормально и именно так всё реализовано в GPU. В альтернативном случае прибавляется смещение на 0,5 и деление происходит на 256, поэтому целочисленный 0 соответствует 0.5/256=0.001953125. Это неудобно, потому что код обработки изображений, например, без знания константы не сможет обнаруживать чёрные пиксели. Из‑за этого мы привязываем логику к 8-битным значениям, даже если вычисления выполняются с плавающей запятой. В стандартном решении всегда можно предполагать, что чёрный соответствует 0.0.

Однако некоторых программистов всё равно притягивает альтернативное решение. В чём дело? Чем оно им так нравится?

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

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

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

Привет, Хабр! Представим: финансовая организация получает из ЕСИА подтвержденные сведения о клиенте, завершает дистанционную идентификацию и принимает его на обслуживание. Позднее выясняется, что операцию совершал мошенник. Паспорт оказался утраченным, изображение документа – отредактированным, а доступ к учетной записи – скомпрометированным.

Кто отвечает? Оператор ЕСИА, потому что сведения пришли из государственной системы? Организация, которая приняла решение обслужить клиента? Или тот, кто когда-то разместил в системе недостоверные данные?

Интуитивный ответ – «если государственная система сказала, что все в порядке, какие могут быть вопросы к бизнесу». Юридический ответ устроен сложнее: подключение к ЕСИА распределяет функции между участниками процесса, но не переносит всю ответственность на оператора системы. Разберемся, где проходит эта граница и как построить технологический контур идентификации, который не сводится к одному зеленому чекбоксу.

Эту статью мы подготовили совместно с Национальным советом финансового рынка (НСФР). В основу юридической части легло заключение НСФР о правовых условиях использования решений Smart Engines для получения и проверки сведений, необходимых финансовым организациям при идентификации клиентов.

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