Серия «распознавание номеров»

Предыдущие части: Часть 1 | Часть 2 | Часть 3

Привет!

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

Спойлер: я изобрел велосипед, но сам!

Спойлер 2: Система еще на этапе разработки, пока только делюсь с вами процессом.

Как это всё начиналось — версия 2022 года

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

В целом выглядит логично. На практике — куча ограничений:

Не каждая камера умеет автоматически определять транспортное средство из коробки. Настройка FTP на камере c кривой прошивкой — это отдельный квест.

У серьёзных брендов всё это есть, но мой проект был рассчитан на сегмент попроще, где камера с AliExpress. С непонятной прошивкой)

Там никакого FTP нет а если есть, работает по настроению. Кстати у меня как раз такая камера)

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

Недавно я решил переделать всё с нуля, первое решение было очевидным: система должна сама анализировать RTSP-поток. Подключил камеру — и забыл. Никаких FTP, никаких триггеров на стороне камеры, никаких танцев с бубном при настройке.

Так я пришёл к связке YOLOv8 + ByteTrack + OCR для номеров. YOLOv8 находит автомобили в кадре, ByteTrack следит за каждым из них как за отдельным объектом, OCR(оптическое распознавание символов c кадра) читает номер.

Архитектуру я продумал заранее. А вот с реализацией — всё оказалось сложнее, чем казалось.

Первый запуск. Первое видео

У меня не было реального RTSP-потока для тестов. Пришлось скачивать видео с YouTube — записи с трасс, парковок, перекрёстков. Качество разное, углы обзора разные, трафик машин разный.

Я не стал хвататься за всё сразу. Решил начать с того что казалось самым сложным — видео с трассы. Камера специально установлена для фиксации номеров, машины едут под одним углом, номер всегда в кадре, никаких засветок. Идеально сложные условия, как мне тогда казалось. Отрезок на распознавание небольшой, скорость у машин высокая.

Запустил. В логах поплыли результаты распознавания. "УРА!" — подумал я. Проект закончен, я молодец.

Потом открыл папку с сохранёнными кадрами...

Система радостно фиксировала каждую машину в момент когда та только появлялась в кадре. На фото — наверное 20% автомобиля, остальное за краем экрана. Я-то понимаю что это машина и что она сейчас въедет полностью, и можно поймать более удачный кадр. Система — нет. Только увидела авто — сохранила.

Проблема первая: кадр слишком ранний

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

Но какой кадр лучший? Первое что пришло в голову — тот где машина занимает наибольшую площадь в кадре. Больше площадь — машина ближе, номер крупнее, читать легче.

Так появилась первая переменная в коде:

BEST_FRAME_WINDOW — сколько кадров собрать для анализа

Стало лучше. Но не идеально. Машина "максимально" в кадре, но номер плохо читаемый, вот бы захватить кадр чуть-чуть раньше....

Проблема вторая: кадр большой, но неудачный

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

Тут я вспомнил что OCR-движок вместе с результатом отдаёт уверенность — число в диапазоне от 0 до 1 насколько он сам уверен в своём ответе.

Теперь правлю логику: если система несколько раз попробовала распознать номер(помним про BEST_FRAME_WINDOW ) и получила результаты с разной уверенностью — берём тот где уверенность выше.

Теперь логика выбора кадра стала такой: не просто "наибольшая площадь", а "наибольшая уверенность OCR". Если OCR вообще не сработал ни на одном кадре — тогда fallback на наибольшую площадь.

Появилась ещё одна переменная:

RECOGNIZE_INTERVAL — OCR запускается раз в N кадров

Парковка и пробка — где всё сломалось и перестало работать

Трасса оказалась самым простым случаем. Машины едут быстро, в кадре недолго, в кадре одновременно 2-3 штуки максимум. Номер всегда видно.

Настоящий ад начался когда я взял видео с парковки.

Парковка: машина стоит и это проблема

Попробуйте угадать что произошло. Подсказка: машина стоит на парковке и никуда не едет.

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

Решение: кулдаун. После того как событие зафиксировано, на этом номере N секунд тишины.

COOLDOWN_SECONDS — пауза между повторными записями одного и того же номера

Особенно актуально для пробок и перекрёстков — там машина может стоять в кадре несколько минут, медленно ехать, снова стоять и так далее.

Пробка: всё сложно одновременно

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

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

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

Режимы: single и multi

Single — для сценариев где в кадре одна машина: ворота, въезд, автосервис. Меньше нагрузка на систему, логика проще.

Multi — для потока: дорога, парковка, пробка. Здесь будет задействован ByteTrack — каждой машине присваивается уникальный ID и система следит за каждым авто независимо.

Добавляю очередные параметры в систему:

DETECTION_MODE — single или multi

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

В multi-режиме каждая машина живёт в своём "треке" — система помнит её историю, лучший кадр, лучший результат OCR, и ждёт финала когда машина уедет.

Триггерная зона: подсказываем системе где смотреть

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

Незачем гонять OCR на весь кадр всё время. Можно заранее сказать системе: "смотри только вот в этой области". Если машина туда ещё не въехала или уже выехала — OCR не запускаем.

Новые параметры:

TRIGGER_ZONE_TOP — верхняя граница зоны (доля высоты кадра, 0.0–1.0)

TRIGGER_ZONE_BOTTOM — нижняя граница зоны

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

Streak и ранее сохранение: не ждём вечно

Ещё одна история из пробки. Система честно ждала пока машина уедет из кадра, и только потом финализировала событие. Логика правильная — но на практике машина в пробке в кадре может ехать три минуты или десят. Все это время ждать результата?

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

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

Несколько раз подряд один и тот же номер — streak набран. Система не ждёт пока машина уедет за кадр, она уже уверена в ответе. Событие сохраняется прямо сейчас, с кадра №3 где уверенность максимальная.

А вот другой сценарий — номер то появляется, то перекрывается соседним авто:

На второй попытке номер считался неполностью — streak сбросился. Счётчик начинается заново с попытки №3. На попытке №4 снова два совпадения подряд — сохраняем событие

Это называется streak — серия одинаковых результатов подряд. Набрали нужное количество совпадений, достигли нужного уровня уверенности — "отпускаем" машину не дожидаясь её физического ухода из кадра.

Новая переменная:

PLATE_CONFIRM_COUNT — сколько одинаковых OCR-результатов подряд нужно

для уверенного распознавания

Пресеты: чтобы не настраивать каждый раз вручную

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

Трасса — машины быстрые, нужен маленький DISAPPEAR_FRAMES.

Ворота — одна медленная машина, совсем другая логика.

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

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

Схема логики детектора

Чтобы было понятнее как всё это работает вместе — вот упрощённая схема.

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

Конечно, система сложнее, я описал только основные моменты логики и проблемы с которыми столкнулся.

Что в итоге

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

Каждая переменная — это конкретная проблема которую я встретил в ходе разработки. Не наугад , а именно: "вот кривое распознавание, вот так можно починить, вот ручка/переменная чтобы можно было отрегулировать".

Всем привет!
INTRO
Это вторая часть статьи о том, когда It-шнику становится любопытно. Как я решил при помощи простой ip-камеры создать сервис регистрации проезжающих автомобилей с блек-джеком и шлю… распознаванием номера.

Часть пятая. Поиск оборудования. Форм-фактор.
По предварительным испытаниям стало совершенно точно понятно, текущая ip-камера не подходит и необходимо что-то лучше.
Т.к у меня совершенно нет понимания, что происходит на рынке видеонаблюдения, я начал читать какие-есть типы камер и чем они отличаются.
Для начала расскажу вам какие типы камер бывают. Разделить можно на два основных раздела, это IP и Аналоговые камеры. Для себя я выбрал первый вариант по следующим причинам:
• Простота установки. Не требует дополнительного оборудования
• Настройки осуществляются в самой камере
• Возможность обработки видеопотока непосредственно на камере
Следующий момент — это форм-фактор. Не сказать, что для меня он играет важную роль, но мне бы хотелось иметь возможность установить камеру на улицу и иметь возможность легко выставлять кадр.

Корпусные камеры.
Пожалуй, самый классический форм-фактор — это «корпусные камеры». Это камеры, которые мы чаще всего представляем в своей голове. Пример на рисунке 1.

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

Купольная PTZ-камера.
Когда смотрел различные обзоры, часто встречал слово PTZ и не понимал, что оно означает. Рассказываю – это полный аналог купольной камеры, только поворотный механизм объектива управляется удаленно. Пример на рисунке 2.

Поворотная PTZ-камера
Форм-фактор здесь может быть различным, но главная функция — это удаленное управление поворотом камеры. Пример на рисунке 3.

Итак, для себя решил, мне подойдет классическая корпусная камера.

Часть шестая. Поиск оборудования. Функционал
Одной из основных задач моего проекта – обработка информации с камеры.
Первоочередно я искал камеры с поддержкой RTSP потока. Для начала я понял, что выбирать среди лидеров рынка оборудования видеонаблюдения я не буду, как бы странно это не звучало. Цены на оборудование бренда hikvision и прочих сильно противоречат одному из требований, оговоренных мною ранее – дешевизна решения. Стал искать среди популярных китайский брендов.
Составил для себя ТОП:
• Gadinan
• BOAVISION
• GCraftsman
• Reolink
Когда начал знакомиться с решениями данных производителей – был приятно удивлен, адекватные для домашнего сегмента цены и неплохие технические характеристики на бумаге. Но все мы с вами знаем о качестве китайского ПО – классные функции на бумаге легко разбиваются о бесконечные глюки и зависания)
Сравнивая различные модели, прочитав множество обзоров и отзывов на работу камер, я определил для себя бренд reolink. Меня очень привлек следующий функционал:
• Распознавание человека
• Распознавание автотранспорта
Возможность отправки уведомлений:
• Загрузка на FTP
• Отправка на email
По итогу я заказал себе камеру RLC-811A (на момент покупки цена 5900руб.)
Основные характеристики:
• POE
• 8MP
• ИК – подсветка
• Светодиодная подсветка
• Слот для SD-карты
• Пятикратный оптический зум
Камера в пути, тем временем продолжаю остальную подготовку.

Часть седьмая. Логика системы.
Теперь вводные немного изменились. Моя новая камера может самостоятельно определять автомобиль в кадре и отправлять уведомление на почту или FTP. Это снимает с меня необходимость в реальном времени самостоятельно обрабатывать видеопоток, теперь мне нужно обрабатывать входящие алерты (оповещения), которые мне отправит камера.
Тогда этапы взаимодействия в системе должны быть следующими:
1. Камера отправляет алерты на сервер(ftp) или почту
2. Моя система принимает входящие данные
3. Данные обрабатываются
Здесь стоит вспомнить еще об одном требовании, которое я для себя выставил – поддержка нескольких пользователей.
Значит необходимо продумать канал для передачи уведомлений. Я решил, у каждого пользователя должны быть свои собственные реквизиты, будь это директория и пользователь ftp или почтовый ящик для отправки.
Вариант с FTP я посчитал недостаточно безопасным. Email подходит намного лучше т.к позволяет гибко управлять настройками почтового ящика и обработкой писем.
У каждого пользователя может быть свой почтовый ящик, у кого-то mail.ru, кто-то пользуется gmail, yandex .и.т.д – при работе с каждым из этих провайдеров можно столкнутся с различными проблемами. Например, gmail с недавних пор вообще запретил подключать свою почту к различным умным устройствам и сторонним приложениям.
Придется создать свой почтовый сервер. При регистрации нового пользователя в системе ему должен быть автоматически создан почтовый ящик и предоставлены подробные настройки для камеры. Пользователь вводит данные настройки в камеру и теперь все уведомления отправляютcя через мой почтовый сервис, которым я могу гибко управлять.

Итак, новая схема теперь выглядит так:

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

Часть восьмая. Установка камеры.
Пришла долгожданная посылка! После домашней мини-камеры от xiaomi новая кажется гигантом.

Изначально я планировал питать камеру через PoE…

Проблема первая. Из коробки камера не запустилась. Как оказалось, мой роутер Микротик подает слабый вольтаж на PoE и необходимо сменить блок питания роутера. Т.к час был поздний и запустить камеру хотелось очень сильно, решил запитать камеру по отдельной выделенной линии питания, к счастью, в коробке с проводами( у всех же такая есть?) нашел подходящий блок питания на 12v.
Вставил витую пару, подключил питание и через пару секунд камера успешно запустилась. Фирменные приложения в телефоне и на компьютере уже были на готове, камера быстро нашлась в сети, и я успешно подключился.

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

Настроил микротик в режиме wifi-репитера и уже по витой паре от него раздал интернет на камеру. В итоге схема получилась следующей:

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

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

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

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

При такой установке камеру невозможно наклонить вниз и снимать она будет под углом 90 градусов, мне это, конечно, не подходит т.к необходимо снимать дорогу внизу. Что ж… Я создал проблему и героически её решу!
Сделал из металлического профиля уголок, к которому на крепеж присоединил камеру. Схематично выглядит так.

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

Проблема пятая. Оборудование установлено, вроде работает. Проверяю качество картинки днем, с помощью зума – отлично! Номера прекрасно читаются

Но… наступает ночь и что я вижу – а ничего! Точнее видно все, кроме номеров. Ик-подсветка сделана у камеры на совесть и засвечивает номера превращая их в сплошной белый прямоугольник.

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

Готово! И так с камерой на текущем этапе разобрались (на самом деле есть еще одна серьёзная проблема, но о ней позже), теперь возвращаемся за компьютерный стол.

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

Шутка, но она не далека от правды.

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

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

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

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

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

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

Финишная прямая.
Статья получилась большой, но аккуратно разбить её я не смог. Надеюсь вам было интересно наблюдать за моим небольшим домашним проектом.
Выше я писал, что с камерой есть еще одна серьезная проблема. Я вам её покажу:

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

Полезная информация для самых терпеливых :)

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