Nuzhny

Непонятно, что за эксперименты ты проводил. Я кидал выше ссылку с экспериментом с рукой, он работает и там сказано, что означает каждый из коэффициентов - каждое из расстояний. Разумеется, что 0 не обязательно означает абсолютное совпадение. Например, корреляции совпадение будет равно 1. Далее, похожесть по цвету в RGB выразить трудно или невозможно. Размывать гистограмм у можно, хуже не будет. Но можно просто взять размер бина побольше, что будет равносильно box фильтру. Ну игистограммы не идеальны, тут никто не спорит, но проблема не в OpenCV. На OpenCV проще с ними экспериментировать, потому что почти всё необходимое уже реализовано. Последнее: гистограммы должны быть только частью веса ребра графа, поток в котором мы ищем. Повторюсь, что надо комбинировать признаки.

Надо выбрать правильный размер бина. Если ты знаешь, что яркость картинок может отличаться на 20-30, то и размер бина надо брать не 1, а больше. Рекомендую Евклидово расстояние вообще не использовать, а для начала просто поиграть со встроенными функциями из OpenCV, убедиться, что они подходят или нет, а уже потом писать самому. Почему не использовать Евклидово расстояние? Потому что гистограмма по своей природе больше похожа не на дескриптор, а на выборку из некоторого распределения. Соответственно и проверять насколько одно распределение похоже на другое. Формула там, кстати, очень простая, распределение дискретной, поэтому никаких интегралов: https://docs.opencv.org/3.4/d8/dc8/tutorial_histogram_comparison.html

Да, именно последнее. Если посмотретьна результаты трекинга одного объекта в VOT 2018, то в победителях уже сиамские нейросети. У них свои недостатки, например, их реалтайм - это реалтайм на GT 2080 Ti, что совсем грустно. Реализаций полно на Гитхабе, например тут и тут.

Самый простой и быстрый способ, который используется в том числе в particle filter - это сравнение гистограмм. Построить гистограмму объекта при обнаружении, далее сравнивать с гистограммой объектов на последующих кадрах, при сооттветствии обновить. Рекомендую сравнивать гистограммы методом Бхатачарья (есть в OpenCV) или нессиметричной метрикой из другой области - расстояние Кульбака-Лейблера (нет в OpenCV). Второй, более популярный на данный момент способ - это считать HOG-дескриптор и сравнивать его. Ну и третий способ, самый точный и популярный на сегодняшний день - это сиамские нейросети. Но, думаю, тебе хватит и первых двух. Тут надо заметить, что в классическом смысле метрика может быть абсолютно любой, вплоть до линейной (или нелинейной) комбинацией всех перечисленных и других. Например, взять 3 метрики: расстояние Жаккара (его называют IoU, intersection over union), расстояние между гистограммами и евклидово расстояние между HOG дескрипторами. Тогда итоговое расстояние будет равно: D = w0 * IoU + w1 * HistDist + w2 * HOGDist, где w0 + w1 + w2 = 1. Линейной комбинацией может быть такой вариант: w0=0.5, w1=0.2, w2=0.3. То есть мы требуем хорошего пересечения описывающих прямоугольников, из-за проблем со светом влияние похожести гистограмм сводим на минимум, а похожесть HOG'ов влияет средне. Эти коэффициенты надо подбирать не вручную, а написать тесты, разметить ролики и запустить перебор вариантов на достижение наилучшего качества. Нелинейной комбинацией можно достичь бОльшего. Например, если IoU < 0.1, то уже совсем не считать HistDist и HOGDist, а сразу говорить, что расстояние равно D = 0. Вариантов много, для каждого конкретного случая можно подобрать свою удачную комбинацию.

Это или это не работает?

Глава 12. Сетевые настройки. Эх, приходится советовать открывать паспорт.

Без CUDA тоже будет работать, но медленней. По факту ключевые точки на лице ищутся не методом Виолы-Джонса, им только лицо, а точки уже другими способами: AAM, нйросети (регрессия) и т.д. Возможно, тебе подойдут active shape models, которые до нейростей были лидером по качеству и не требовали видеокарты. Хотя сейчас с OpenVINO многие нейросети и так быстро работают.

Да, всё верно, сегменты привязываются к объектам. Каждый объект может хранить у себя не только последние координаты, но и число-счётчик: на скольких последних кадрах он был найден. Если потеряется в середине кадра и не найдётся, скажем, в течение секунды, то считать потеряным и удалять. Если найдётся, то обнулять счётчик. В реальности его можно ещё и доискивать, если не найден, но это уже может быть не реалтайм. Также можно в каждом объекте хранить его модель движения: в простейшем виде это просто скорость: сколько пикселей за 1 кадр он проходит по Х и по У. Чуть сложнее - линейный фильтр Калмана из OpenCV или самому. Тогда, если 2 человека объединились в 1 объект, один человек станет типа потерян. Но на каждом кадре всё равно изменять его последние координаты с помощью известных скоростей или фильтра Калмана. Получится, что в момент разделения потерянный объект "пройдёт" это расстояние сам по инерции.

Ну, результаты детекции выглядят очень неплохо. Просто применить классический венгерский алгоритм разве не получится? В качестве метрики между объектами использовать расстояние Жаккарда (IoU) - отношение пересечения прямоугольников к объединению. Кажется, что работать будет и быстро, и точно

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

В OpenCV есть cv::viz, который умеет.

Вариантов много. Ну и реал-тайм - это не требования. Правильное требование: процессор + память + видеокарта, разрешение видео и сколько времени на обработку одного кадра. А то может оказаться, что детекцию нейросетями надо будет делать на слабом CPU и 25 кадров/сек на видео 6МП. Хотя тут тоже можно натренировать tiny YOLO или MobileNet SSD.

На первый взгляд кажется, что можно - мы же глазами видим движение по изображению с этой камеры. Очевидно, что классическое вычитание фона тут не справится, потому что оно смотрит на изменение интенсивности пикселей. Первая мысль - избавиться от цвета, то есть перейти в цветовое пространство типа HSV или Lab, а далее работать исключительно с каналом интенсивности (V или L). Далее использовать dense optical flow, например Farneback, получить поле векторов. Далее это поле уже сегментировать (kmeans или что-то сложнее). Результатом сегментации должны стать уже блобы и фон. Это так, взгляд со стороны.

То есть никакого детектора нет? Есть возможность снимать камерой с датчиком глубины? Или камерой в ИК диапазоне?

А что вообще есть на входе? Обычно трекинг понимается в 2-х ипостасях: 1. Visual objects tracking (VOT). Всё это направление подразумевает, что на первом кадре объект как-то нашёлся (детектором, классификатором или был выделен оператором), а дальше на каждом кадре его ищет исключительно сам трекер. Тут можно посмотреть на модуль tracking из opencv_contrib, в частности на CSRT оттуда. Другой классический метод - это STAPLE, но лидеры на сегодняшний день - сиамские нейронные сети (там и датасет, и результаты, и победители). 2. Tracking by detection. Тут принцип другой: непрерывно на видео работает детектор, объект(ы) находится достаточно регулярно. Если объект не находится, то его траектория интерполируется (фильтр Кальмана), он доискивается с помощью VOT и т.д. Когда объект снова находится, то срабатывает какой-то re-id, чтобы узнать, что найден именно тот самый объект (re-id - это сравнение размеров, гистограмм, нейросети и т.д.). Если используется трекинг сразу нескольких объектов, то необходим алгоритм межкадрового связывания: для двух кадров Венгерский алгоритм или аналоги, но популярнее сейчас поиск максимального потока в графе, например.

Тогда так просто с дивана трудно сказать в чём причина. Реально так и происходит, когда некоторых ресурсов не хватает или есть просадки по времени: в кадре появляется большой объект или движение самой камеры, поток с камеры резко возрастает на P или B frames и они не успевают декодироваться либо теряются. Ведь битрейт - это что-то среднее в секунду, а тут резкое в 1-2 кадра увеличение изменений. Можешь ещё поставить fixed bitrate, если камера это умеет. Кстати, а какая частота I-frames? Обычно он идёт раз в 1-2 fps, то есть у тебя каждый 25-50 кадры.

Неплохо получилось. 1. Ложные срабатывания на качающихся деревьях и проводах можно легко отбросить с помощью простой оценки плотности: N_pix / A_bb > alpha, где * N_pix - число пикселей переднего плана внутри прямоугольника; * A_bb - площадь прямоугольника (width * height); * 0 < alpha < 1, например alpha = 0.3. Физический смысл очень просто: когда качается ветка или провод, то прямоугольник получается большим, а самого объекта в нём очень мало. Если плотность больше некоторого небольшого alpha, то объект реальный. Иначе отбрасывать. 2. NV12, YUV420, YUV422, YUV444 - это нормально для h.264, RGB там не бывавет. 3. Глюки сигнализируют о том, что потерялся кадр. Причин может быть много: - потерялся в сети, тут можно уменьшить битрейт, можно снизить частоту ключевых кадров; - не успевает декодер - можно попробовать другой, лучше аппаратный; - у тебя однопоточное приложение и все действия (декодирование, детекция, отображение) в сумме занимают больше 1000 / fps млсек. Тогда кадры будут время от времени отбрасываться.

Не знаю, что там скроется внутри в шарповом коде, но в OpenCV есть HoughLines (Standard Hough Line Transform) и HoughLinesP (Probabilistic Hough Line Transform). Так второй вариант работает намного лучше. А в opencv_contrib есть ещё и более быстрый вариант FastHoughTransform. Ещё есть cv::LineSegmentDetector, который и быстрый, и может находить короткие отрезки. В общем, я бы сначала поэкспериментировал с тем, что есть.

Формат форума обычно подразумевает описание проблемы, а потом коллективно ищется решение. Такой формат не подходит?

Лучше 80х80. Далее идёт детекция через cv::CascadeClassifier::detectMultiScale, где можно подобрать правильный коэффициент скейла. Тренироваться может долго, но тут никуда не деться. В плане альтернатив из коробки есть ещё SVM+HOG, но это будет уже медленнее Хаара.

Если размер объекта у тебя никогда не будет меньше 100 пикселей, то можно ставить минимальный размер и больше, чем 20х20, тут проблем у меня не было. P.S. В OpenCV 4 тренировка каскадов уже depricated, а opencv_createsamples удалена из сборки. Фактически есть, но закомментирована и, если включить, не собирается из-за чистки старого API. Так что надо подумать, насколько необходимо использовать каскады Хаара в будущем.

Да, косяков там достаточно, это старый мой код, которому уже больше 10 лет: люди "распадаются" на части и т.д. Но она на тот момент предназначалась для детекции движения и определения оставленных предметов и с этим справлялась. Сумка становится сиреневой - это как раз момент, когда вышел заданный таймаут (там он установлен секунд в 15 для наглядности) и объект считается фоном. Даже если сумку унесут, рамка какое-то время будет на этом месте, чтобы сотрудник безопасности обратил на это внимание.

1. Цвет учитывается в большинстве методов. Есть только нюанс: почти везде работа ведётся с цветными изображениями так, как будто они состоят из равноправных цветовых каналов. Например, для MOG2 из opencv_video нет разницы, подашь ему RGB, BGR или HSV. Хоть там и есть возможность детектирования теней (detectShadowGMM), но оно совсем не будет работать, если подать неправильную картинку. А некоторые методы изначально ориентированы на то же детектирование теней, что очень востребовано, если надо считать автомобили или людей, а не просто их детектировать. Про текстуры и контуры я не в курсе, не слышал. 2. Длительное присутствие или детекция оставленных объектов, как мне кажется, требует самостоятельной модификации метода и принципиально не может быть реализовано силами алгоритма вычитания фона. Если он может адаптироваться к изменению фона, то рано или поздно адаптируется к любому изменению. Если не может адаптироваться, то со временем накопится такое количество ложных пикселей заднего плана, что всё станет белым. Когда я занимался этой проблемой, то сделал что-то типа самопального MOG, у которого не было возможности самостоятельной адаптации. После вычитания фона отрабатывал трекер объектов и их распознавание. Если объект был маленький (а надо было детектировать только большие) и неподвижный, то включалась адаптация внутри этого объекта. Если объект был большой и неподвижный, то адаптация не включалась. Также она не включалась, если объект был распознан, как пешеход или автомобиль. Далее был интервал в несколько минут, в течение которого неподвижный объект считался оставленным. Объект неподвижен, скажем, минуту - адаптируем фон под него и выдаём оператору, что обнаружен оставленный предмет. Если долго был неподвижен автомобиль, то просто адаптируем фон под него. Если же распознавание не использовалось, то просто адаптируем фон для всех объектов после истечения некоторого интервала. Вот как это примерно выглядело для видео с PETS 2006: сумка из зелёной сначала становится красной, а потом сиреневой. 3-4. Это тоже делалось вручную, но с внешними наворотами. Для всех систем видеонаблюдения полезно иметь алгоритм саботажа или порчи камеры: засветка, расфокусировка, закрытие объектива и т.п. То есть такой детектор работает независимо от детектора движения и в случае обнаружения неполадок отдаёт команду детектору движения, по которой он переинициализируется. Кажется, что силами алгоритма вычитания фона это тоже не так просто сделать. Одно время появился закрытый и запатентованый алгоритм vibe, который был и очень быстрым и точным. Через некоторое время патент кончился и его автор бельгийский профессор открыл исходники. Кажется, они уже есть в bgslibrary. Можно начать с него.

Да, здесь есть реализация и статья-обзор нескольких десятков методов вычитания фона. Там намного больше всего, чем есть в OpenCV и лучше структурированы. И не надо забывать про базовый videoio - там тоже кое-что есть проверенное временем. А чего хочется от вычитания фона? Может, просто написать тестовое окружение и посмотреть на результаты, выдаваемые каждым алгоритмом?

Да, должно работать. Утверждать ничего не буду, но обычно копируется весь кадр. Посмотри, как это делается в ffmpeg: функция dxva2_transfer_data. Там лочится поверхность, что означает копирование всего содержимого из видео в системную память (указатель в LockedRect содержится). А потом уже из системной памяти копируется куда надо. Трудно сказать, что будет происходить на Атоме, почему там такая высокая загрузка на этой операции. Когда лочится поверхность, находящаяся в видеопамяти дискретной видеокарты, то память копируется с помощью DMA, минуя процессор. То есть мы получаем задержку, но процессор остаётся свободен. Тут же дискретной видеокарты нет и память просто копируется из системной в системную? Я не знаю.