Nuzhny

Я уже несколько лет не занимался всем этим видеозахватом. Но сегодня увидел предложение отключить в OpenCV поддержку vfw и DirectShow как устаревшие технологии. Поэтому я бы не стал доверять OpenCV в таком вопросе. Я не о том, что они что-то неправильно делают, технологии и правда очень старые, им десятилетия. Но если захват видео с требуемой скоростью - это критическая задача, то лучше делать всё самому на требуемом API, а не полагаться на стороннего разработчика, который в угоду стройности идей своей библиотеки может либо замедлить, либо отключить что-то важное. Всё таки в OpenCV видеозахват - это не главное. Важно только, чтобы он был.

Можешь это попробовать: http://www.infognition.com/GraphEditPlus/

Думаю, что для получения такого высокого fps всё равно прийдётся разбираться с захватом видео на низком уровне. Почему DirectShow может тормозить? Потому что там может стоять не только Frame grabber, но и несколько других фильтров, которые в обычных условиях практически не дают дополнительной нагрузки, немного улучшая качество видео. А это дополнительные копирования памяти. Какое разрешение видео? Если FullHD, то при 330 fps и кадре RGB мы получим поток: 3 байт/пиксель * 1920 * 1080 * 330 = 2 Гбайта/сек. Многовато? Да. С такими объёмами надо минимизировать количество копирований и выделения памяти любыми способами. Чем декодируется видео? Аппаратным декодером или программным? Надо убедиться, что аппаратным. Почему древний vfw может быть быстрее DirectShow? Потому что он ничего не умеет, кроме самых базовых вещей, вот и работает быстрее. Копирует ли OpenCV внутри себя память, когда он выдаёт наружу cv::Mat? Да, копирует, а это лишнее. Поможет ли Линукс и/или более мощный комп? Может помочь, а может и нет, зависит от причины тормозов. Я бы всё таки начал с GraphEdit и посмотрел на результат.

Я так понимаю, что тут 2 вопроса: почему не 330 захватывается и почему только 60 выводится. Захват осуществляется не самой OpenCV, который выступает исключительно в виде фронтэнда в этом случае, а с помощью одного из используемых бэкэндов. Надо узнать, что это за бэкэнд! Думаю, что для web-камер под Windows используется DirectShow или vfw. Классический VirtualDub использует vfw, скорее всего OpenCV 2 также. Отсюда и высокий fps. Предположу, что OpenCV 3 использует уже DirectShow, поэтому получается медленнее. Можно взять VirtualDub DirectShow mod, лучше просто GraphEdit и проверить что да как. В GraphEdit можно и подобрать правильные фильтры/муксеры/декодеры для получения максимального fps. Посмотреть в стороны DXVA2. Ну и узнать в конце-концов, чем декодирует OpenCV и где тормоза с помощью профайлера. Всё таки библиотека опенсорсная, надо пользоваться этим.

Я полностью согласен на счёт ближайших соседей. С моей стороны была ремарка по поводу среднего значения, которое очень часто не подходит никак. Медиану же можно считать не абсолютно точно (для float-point такое вообще невозможно), а как среднее значение в небольшом окне. Грубо говоря, построить гистограмму, где бины идут с некоторой шириной (погрешность), взять максимум. Тоже не для всех случаев подходит, но почти всегда лучше среднего.

Так и есть. По факту, там просто ожидание получается больше, чем 40 мс, вот нагрузка и кажется ниже. Вычислений же меньше не делается. Пути уменьшения нагрузки 2: увеличивать время простоя или оптимизация узких мест. P.S. Кстати, если тебе RGB изображение не нужно, то можно оставаться в рамках YUV и убрать sws_scale, нагрузка снизится. Я вообще слабо представляю зачем может понадобиться RGB и откуда он берётся. С камеры получаем raw, который близок к RGB, но не он, а по факту Bayer. Если мы получаем видео с веб-камеры, то там может быть RGB. Если из h264 или jpeg, то уже YUV. Это явно твой случай. Далее идёт анализ. Куча алгоритмов работают с grayscale картинками. Как мы получаем их? Правильно, конвертируем YUV -> RGB -> Gray. Но можно было просто взять первый Y канал из YUV безо всякого копирования памяти. То есть в привычном сценарии делается две (!!!) лишних конвертации с копированием памяти и потерей данных при этом.

Правильней заполнять не средним, а медианой. Например, есть чёрный и белый цвет. Заполнить средним - серым будет совсем не правильно, а медианой (какого цвета больше) точнее.

А стандартный вариант: std::this_thread::sleep_for(40ms);

Тогда надо смотреть на твоё видео или подробней опиши входные данные. Может я уже показывал тут раньше своё. Эта работа была сделана лет 10 назад по описанному мной алгоритму. Ближе к концу видео видно, что остановившаяся машина обводится синей рамкой - считается оставленной. Далее я выхожу с сумкой, оставляю её и ухожу - тоже обводится синим, на неё наводится камера. Скажу, что данный подход частично справлялся и с PETS 2007. А там видео намного сложнее. Сейчас, я бы действовал уже по-другому. Для того же PETS 2007 лучше бы комбинировал вычитание фона с распознаванием тем же YOLO, отделяя сумки от людей. Может, ещё что-то добавил бы. И отслеживал бы всё по отдельности.

Я раньше делал достаточно просто: использовал обычный детектор движения (камера была неподвижная), треки объектов отслеживались, время от времени запоминал изображение объекта. Когда объект пропадал, то искал его в окрестностях по последнему его сохранённому изображению (cv::matchTemplate). Если объект оставался на месте в течение какого-то времени (скажем, минуты), то он считался оставленным. Такой подход неплохо работал и не тормозил.

Имеется в виду детектор оставленных и унесённых предметов в системах видеонаблюдения?

dlib они использовали раньше. Сейчас тоже используют, но не исключено, что и своё тоже есть. Я привёл их в качестве примера детекта точек на видео, где качество обеспечивается не только детектированием, но и трекингом. Вчера был на выступлении директора Noldus'а по FaceReader'у. Они используют для лиц AAM, а на лице находят 500 точек! Выглядит круто, работает тоже неплохо - демонстрация на встроенной вебке с ноута для презентаций была. Но это профессионалы, которые на рынке уже очень долго.

Направь логи в файл и там посмотри. Или какой-нибудь IDE собери. На счёт protobuf ответ простой - всё меняется, оазвивается opencv_dnn, которая его и требует (ещё из contrib).

Ещё есть dlib и в самом OpenCV (в opencv_contrib) есть Facemark API с тремя способами нахождения точек на лице. Я его и использую. Но не уверен, что с этими библиотеками получится достигнуть принципиально лучшей точности. Для трекинга точек есть отличный проект OpenFace, где не ограничиваются исключительно детекцией точек на каждом кадре, а ещё и их трекинг производят (и многое другое), что позволяет устранить огрехи детекции. Не призываю использовать именно этот проект, но он показывает правильное направление.

Судя по всему, у тебя в CMake должны быть установлены опции типа BUILD_PROTOBUF=ON. Это означает, что будет использоваться версия protobuf, которая поставляется вместе с OpenCV и совместима с ним. Во втором случае на картинке не видна сама ошибка, поэтому не понятно в чём дело.

Но сами разработчики OpenCV так и делают.

Ммм, а в чём сейчас проблема? Фигуры находятся, координаты сторон есть, проблема с определением, что углы прямые?

Не преобразуются в 2 координаты - это гиперплоскость в N-мерном пространстве, где N - размер дескриптора.

Немного о текущей ситуации: добавил к уже имеющемуся алгоритму вычисления пульса по цвету ещё и по микрокачаниям головы (трекинг face landmarks). Но результаты не впечатляют. Идём далее. Как можно обрабатывать временные ряды? Сейчас по выборке сигнала за несколько секунд делается Фурье, ищутся максимумы частоты. А какие механизмы есть для отслеживания этого по времени? Я сделал типа смеси Гауссианов, но кажется, что должно быть что-то более научное. Нашёл статью Variational Fourier Features for Gaussian Processes. Это оно? Правильно ли я понимаю, что этот механизм интегрирует в себе Фурье с Гауссом и может заменить мой велосипед?

Казалось бы так: cv::Mat Mix = img1 * 0.2 + img2 * 0.8;

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

Хорошее описание Facemark API из OpenCV.

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

libfacedetection не в исходниках - не подошёл. Но всё оказалось намного лучше. opencv_dnn уже содержит обученную для лиц модель resnet, работает быстро - проверил. А модуль face из opencv_contrib умеет находить face landmarks. Так что OpenCV порадовал, становится всё более самодостаточной штукой. Всем спасибо. О результатах отпишусь.

Кажется, libfacedetection должен подойти. Потестирую...