Nuzhny

Можно написать декодер ручками на fmpeg и подключить фильтр для получения motion vectors: пример. Только кажется, что игра не стоит свеч: есть работы по детектору движения и трекингу на основе этих векторов, мы сами в АМД пробовали их использовать. Но их качество очень плохое для применения именно в этих целях. И очевидно почему: цельку кодека является не поиск истинного движения или изменений в кадре, а минимизация сжимаемой информации. То есть ему выгодней найти ложные вектора движения блоков, если они в результате дадут меньше передаваемой информации.

Я соглашусь с mult1plexer, сейчас нейросети дадут результат быстрый и устойчивый. Можно начать с U-net, для бинарной сегментации небо-не небо зайдёт хорошо и будет работать быстро. К тому же ему не нужен огромный датасет. Если же хочется классического компьютерного зрения, то всё будет сложнее. Но это точно не уход в серый с градиентами. Я бы всё равно собрал небольшой датасет, обучил бы на нём очень быстрый decision tree из OpenCV, а дальше watershed. Decision tree можно обучать как просто на цвете пикселя, так и градиент туда добавить, если хочется.

Надо искать небо исключительно на одном этом фото? Или задача стоит более обшно? А облака относятся к небу? Небо может быть розовым-закатным, пасмурным, вечерним, со звёздами? Оно будет на каждом изображении гарантировано? Или могут быть изображения без неба? Странный подход, когда отбрасывается вся цветовая информация, казалось бы, небо голубое и это можно использовать. Я бы начал разработку с классики: создания и разметки наиболее поного датасета. Тогда проблема станет видна во всей своей красе.

А в Raspberry можно же воткнуть тот же Intel compute stick и для запуска на нём сеток?

О, тут всё зависит от задачи, для каждой свои рецепты. Шум может быть самый разный: если человек стоит на фоне лестницы, то HOG его не задетектит, потому что градиенты на границе будут ужасными. Такой сэмпл в обучающей выборке тоже будет типа выбросом, который сместит разделяющую гиперплоскость в совсем не ту сторону. Линейный SVM используется потому что быстрый. Тут есть два подхода: либо тщательно подобрать features vector (или сделать для него преобразование типа PCA, PLS....) и использовать линейный SVM или использовать SVM с RBF. Для той же детекции пешеходов используют HOG с линейным SVM, потому что скорость критична.

Тут фишка немного в другом. Я уже говорил, что SVM чувствителен к шуму, особенно линейный. Несколько выбросов могут очень сильно сдвинуть разделяющую гиперплоскость в сторону. Как это можно решить? 1. Можно использовать нелинейный SVM (с RBF ядром, например). Он попытается адаптироваться не только к линейно неразделимым данным, но ещё и к выбросам тоже. Минус нелинейного SVM - он очень медленный. 2. Или же устранить выбросы. Например как? Например, перейти в другое пространство, где этих выбросов практически не будет. Самый простой способ - это PCA (метод главных компонент). Обычно берут многомерный вектор, делают PCA, а после берут оттуда только те компоненты, сумма значений которых составляет 95% от всех данных. То есть откидывают 5% самых малозначащих данных, которые чаще всего являются шумами. Часто получается, что эти 95% важных данных содержат в себе 10-20% компонент. Эта штука фактически представляет собой способность к обобщению и отлично работает с линейно разделимыми данными и устраняет исключительно шумы. Что представляет собой PCA в плане изображений - это силуэт, основные черты. То есть своё изображение по нему ты восстановить не сможешь, но будет точно понятно, что это изображение, например, является силуэтом человека. Ты мог видеть такие статьи ге есть усреднённое лицо человека европейской расы или среднее лицо женщины - это всё PCA. Есть и нелинейные преобразования, позводялющие уменьшить размерность данных и при этом улучшить работу классификатора, например PLS (partial least squares). Вот отличная статья по этому поводу: "Vehicle Detection using Partial Least Squares" Они добавляют к HOG кучу других фич типа симметрии, делают огрочный features vector, а потом его сильно сокращают с помощью PLS и подают его на линейный SVM. Посмотри на рисунок 5 в статье, как данные стали намного лучше линейно разделяться. Что получаем по производительности. 1. На этапе обучения нам надо: 1.1. "Обучить" - построить преобразование в новое пространство с помощью PCA или PLS: из картинок извлечь feature vector'а размера N, слепить их в один большой и вычислить параметры нового многомерного пространства размера N. Выделить значимое подпространство размера M < N. Сохранить. 1.2. Обучить уже классификатор (SVM) на новых feature vector'ах размера M: вычисляем по картинке HOG, применяем к нему PCA, берём M первых значений результирующего вектора. Обучаем на этих данных SVM и сохраняем. 2. Этап распознавания: 2.1. Загружаем PCA и SVM. 2.2. Берём изображение, считаем HOG, применяем PCA, берём M первых значений результирующего вектора, подаём в SVM. Профит! У нас получается, что SVM обучается быстрее и работает тоже, но добавляется умножение на матрицу NxN. В каждом конкретном случае можем получить как ускорение, так и замедление процесса.

Почему удивительно? SVM чувствителен к шуму, тот же PCA или PLS отлично помогают с этим бороться.

LexaP, а этот проект не смотрел? Концепция выглядит очень разумно

1. DPM - Deformable Parts Model. Я когда-то использовал реализацию из libccv, но в OpenCV тоже появилась. Смысл в том, чтобы не просто детектировать объект, но и его части и тот факт, что части расположены в пространстве корректно. Например для лица: можно найти просто лицо, а можно лицо и на нём глаза, рот и нос. Если на лице найдены все эти части, то вероятность правильности решения выше. DPM ставит ещё одно условие: как все эти части должны быть расположены на целом и друг относительно друга: - глаза в верхней части лица, выше носа и рта, а также не друг над другом; - нос в средней части лица, под глазами и над ртом; - рот ниже всех и примерно посередине. 2. CoHOG - Co-occurrence histograms of oriented gradients. Придумана Тошибой и использовалась (используется?) для аппаратного детектирования пешеходов в автомобилях. Там берутся не просто линейно гистограммы, как в HOG, а ещё и учитывается их взаимное расположение, молучается 2D матрица гистограмм.

Так я же выше написал: CoHOG, DPM - это всё как раз про "манипуляции перед отправкой в SVM"

Так, кажется мы говорим немного о разном. Есть HOG - это гистограмма ориентированных градиентов (здесь неплохо описано). Грубо говоря, кусочек изображения разбивается на квадраты (например, 16х16 пикселей), в каждом считаются градиенты (это вектор с углом и длиной), из векторов делают гистограммы, обычно из 9 бинов. Соответственно, кусочку изображения ставится в соответствие несколько таких гистограмм, по числу квадратов. Всё, это HOG. В алгоритме трекинга STAPLE как раз считаются HOG для объекта (fHOG - это быстрый способ вычислять HOG на CPU), а дальше ищется корреляция на следующем кадре. Никакого SVM! Есть такие признаки, как ICF (integral channel feature), которые тоже состоят из HOG в том числе (там ещё серый канал и один цветовой). Пётр Доллар использует их на GPU для детекции пешеходов и лиц, но в качестве классификатора берёт random forest (кажется). Тоже никакого SVM! Dlib на этот счёт не ковырял, но в том же OpenCV можно вполне себе считать HOGDescriptor и подавать его на любой классификатор. Или добавлять к нему любые другие фичи и подавать на любой классификатор уже такой расширенный вектор. Возможно, что тебя смущает тот факт, что Dalal в своей изначальной статье 2005 года изначально использовал HOG и linear SVM, но так это для скорости! Тогда компьютеры были медленные, только Haar или LBP + AdaBoost взлетало. А в библиотеки решение HOG + linear SVM пошло потому что оно SOTA, базовое классическое решение, с которым сравнивают алгоритмы. P.S. Сейчас уже нейросети практически вытеснили HOG + linear SVM из компьютерного зрения. А были перспективные направления развития типа CoHOG или DPM.

Почему нет? По моей ссылке выше HOG вообще никак не связан с SVM, а используется сам по себе.

1. На каком расстоянии и какой размер глаз в пикселях будет на кадре? Глаз - это точка или протяжённый объект? 2. Можно детектировать landmark'и какой-нибудь нейросеткой ( например отсюда ), а потом трекать их, сглаживая погрешности детектора.

Похоже на morphsnakes.

На счёт скорости. Есть fhog, который, вроде как, как раз очень быстро считает HOG. Он есть в dlib, гуляет и просто в исходниках. Например, только вчера видел его здесь.

Оно?

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

ffmpeg сам по себе может что-то и не уметь, если его специально не собрали с поддержкой этого аппаратного ускорения. Хотя логично было бы его включать для интеловских процессоров. Если у тебя есть просто собранный отдельно ffmpeg (или скачанный), то можешь посмотреть, что он умеет и повыбирать разные кодеки из командной строки. Например, команда "ffmpeg -hwaccels" выведен список доступных аппаратных кодеков.

Супер! Глядя на твою работу, кажется, что антлант тянет на себе всю землю. Слишком всё это в отрыве от современных тенденций в индустрии. Ты знаешь, как много разновидностей автономеров только в России? Много! Если интересуют не только российские номера, то можно скачать датасет, например, здесь. Можно посмотреть на этом сайте. Или здесь. Чисто на национальные номера ориентироваться нет смысла, потому что всегда попадаются авто из других стран.

Пропатчить так просто не получится, там весь интерфейс придётся менять для всех бэкендов. Кажется, что надо писать самому на ffmpeg, можно взять код работы с ним из OpenCV в качестве базового. С другой стороны есть cudacodec из opencv_contrib, который, вроде, делает как раз необходимое. Но я его не проверял, ничего не могу сказать.

Получать можно в том же ffmpeg: 1. Если не собран, то собрать ffmpeg с поддержкой cuvid. Проверка: ./ffmpeg -hwaccels 2. При создании AVCodec вызвать avcodec_find_decoder_by_name("h264_cuvid") или avcodec_find_decoder_by_name("mjpeg_cuvid"). 3. Перед вызовом avcodec_decode_video2 устанавливать decCtx->pix_fmt = AV_PIX_FMT_CUDA 4. Тут уже нам возвращают указатель на видеопамять в AVFrame, можно копировать её к себе и обрабатывать: 4.1. Учитываем, что в данном случае у нас кадр не YUV420, а NV12: cudaMemcpy(data, picture->data[0], height * picture->linesize[0], cudaMemcpyDefault) 4.2. Хочется RGB? Вызываем nppiNV12ToBGR_709HDTV_8u_P2C3R 4.3. Хочется засунуть в OpenCV? Вот: cv::cuda::GpuMat* gpuFrame = new cv::cuda::GpuMat(height, width, CV_8UC1, picture->data[0], picture->linesize[0]) Выгрузить из GPU memory и сохранить? Вот: cv::Mat frame; gpuFrame->download(frame); 4.4. Хочется отобразить кадр без копирования в ОЗУ? Создаём OpenGL окно: cv::namedWindow("wnd name", cv::WINDOW_OPENGL) Это про декодирование на CUDA и обработку кадра средствами OpenCV без копирования в системную память. Про TensorFlow: тут надо использовать С++ API, на Питончике такой возможности нет. Добавили такую возможность недавно в версии 1.12: вот обсуждение.

С ip камерами как раз всё проще. Их можно пачкой на CUDA декодировать, а потом обрабатывать изображения, не выгружая декодированные кадры из видеопамяти. Можно отдавать их, например в TensorFlow.

ffmpeg тут ничего нового не придумал, а просто предоставляет обёртку над DirectShow. Я уже давно этой темы не касался, надеюсь, что не навру. Веб камеры в Windows работают через DirectShow драйвер (или WMF) и тут ничего не попишешь. Я очень сомневаюсь, что у них есть что-то своё. Соответственно, при отображении видео используется DXVA - аппаратное декодирование с выводом видео на экран. При этом кадры даже не поступают в оперативную память, а отправляются сразу на аппаратный декодер, встроенный в процессор или видеокарту. Это даже не CUDA или OpenCL, а отдельные специализированные чипы внутри процессора или видеокарты: Intel Quick Sync Video, Nvidia NVENC или AMD Video Coding Engine. Ffmpeg, например, умеет декодировать сетевое видео или файлы и на CUDA - cuvid. Но это уже будет грузить видеокарту, в отличие от полностью аппаратного Nvidia NVENC. Как всё это применить к вебкамерам я, к сожалению, не в курсе.

Веб-камеры используются не по протоколу, а через драйвер. Может оказаться, для неё есть DirectShow драйвер и всё. Но тут ещё вопрос, используется ли DirectShow или сейчас всё реализовано через MSMF. Всё - это dshow и vfw. Думаю, что плайеры работают через DXVA, которое позволяет сразу декодировать и отображать видео. Сходу даже не уверен, можно ли его использовать в OpenCV.

Это уже не ко мне. Напиши сюда.