Перейти к содержимому
Compvision.ru

Nuzhny

Пользователи
 Профиль  Активность

  • Количество публикаций

    1 427

  • Зарегистрирован

  • Посещение

  • Days Won

    176

Сообщения, опубликованные пользователем Nuzhny

  1. Опубликовано · Report reply

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

    Почему DirectShow может тормозить? Потому что там может стоять не только Frame grabber, но и несколько других фильтров, которые в обычных условиях практически не дают дополнительной нагрузки, немного улучшая качество видео. А это дополнительные копирования памяти.

    Какое разрешение видео? Если FullHD, то при 330 fps и кадре RGB мы получим поток: 3 байт/пиксель * 1920 * 1080 * 330 = 2 Гбайта/сек. Многовато? Да. С такими объёмами надо минимизировать количество копирований и выделения памяти любыми способами.

    Чем декодируется видео? Аппаратным декодером или программным? Надо убедиться, что аппаратным.

    Почему древний vfw может быть быстрее DirectShow? Потому что он ничего не умеет, кроме самых базовых вещей, вот и работает быстрее.

    Копирует ли OpenCV внутри себя память, когда он выдаёт наружу cv::Mat? Да, копирует, а это лишнее.

    Поможет ли Линукс и/или более мощный комп? Может помочь, а может и нет, зависит от причины тормозов.

    Я бы всё таки начал с GraphEdit и посмотрел на результат.

    • Like 1

  2. Опубликовано · Report reply

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

    Захват осуществляется не самой OpenCV, который выступает исключительно в виде фронтэнда в этом случае, а с помощью одного из используемых бэкэндов. Надо узнать, что это за бэкэнд! Думаю, что для web-камер под Windows используется DirectShow или vfw. Классический VirtualDub использует vfw, скорее всего OpenCV 2 также. Отсюда и высокий fps.

    Предположу, что OpenCV 3 использует уже DirectShow, поэтому получается медленнее. Можно взять VirtualDub DirectShow mod, лучше просто GraphEdit и проверить что да как. В GraphEdit можно и подобрать правильные фильтры/муксеры/декодеры для получения максимального fps. Посмотреть в стороны DXVA2.

    Ну и узнать в конце-концов, чем декодирует OpenCV и где тормоза с помощью профайлера. Всё таки библиотека опенсорсная, надо пользоваться этим.

  3. Опубликовано · Report reply

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

  4. Опубликовано · Report reply

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

    Пути уменьшения нагрузки 2: увеличивать время простоя или оптимизация узких мест.

    P.S. Кстати, если тебе RGB изображение не нужно, то можно оставаться в рамках YUV и убрать sws_scale, нагрузка снизится. Я вообще слабо представляю зачем может понадобиться RGB и откуда он берётся. С камеры получаем raw, который близок к RGB, но не он, а по факту Bayer. Если мы получаем видео с веб-камеры, то там может быть RGB. Если из h264 или jpeg, то уже YUV. Это явно твой случай.

    Далее идёт анализ. Куча алгоритмов работают с grayscale картинками. Как мы получаем их? Правильно, конвертируем YUV -> RGB -> Gray. Но можно было просто взять первый Y канал из YUV безо всякого копирования памяти. То есть в привычном сценарии делается две (!!!) лишних конвертации с копированием памяти и потерей данных при этом.

  5. Опубликовано · Report reply

    4 hours ago, idrua said:

    Предположим есть датасет с пропусками (часть данных не указана). Можно заполнить средними значениями, что иногда не совсем правильно.

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

  7. Опубликовано · Report reply

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

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

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

     

  8. Опубликовано · Report reply

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

  10. Опубликовано · Report reply

    13 minutes ago, mrgloom said:

    А в OpenFace какие алгоритмы? свой самописный DL?

    dlib они использовали раньше. Сейчас тоже используют, но не исключено, что и своё тоже есть.

    Я привёл их в качестве примера детекта точек на видео, где качество обеспечивается не только детектированием, но и трекингом.

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

  12. Опубликовано · Report reply

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

  13. Опубликовано · Report reply

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

    Во втором случае на картинке не видна сама ошибка, поэтому не понятно в чём дело.

  17. Опубликовано · Report reply

    Немного о текущей ситуации: добавил к уже имеющемуся алгоритму вычисления пульса по цвету ещё и по микрокачаниям головы (трекинг face landmarks). Но результаты не впечатляют.

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

  20. Опубликовано · Report reply

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

    А для твоей цели важны именно символы.

  22. Опубликовано · Report reply

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

    • Like 1

  23. Опубликовано · Report reply

     libfacedetection не в исходниках - не подошёл.

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

    Всем спасибо. О результатах отпишусь.

×