Непостоянная частота камеры

[rushonda]

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

[IvanLis]

У Вас считывание не тактированно, т.е. оно идет с максимально возможной частотой, ограниченной только элементом Wait, то есть чаще нет, а реже да.
Ну и соответственно в зависимости от протокола передачи будет fps плавать, это может быть связано с используемым кодеком, информативностью кадров, нагрузкой на шину по которой передается информация.
Если бы Вы считывали информацию как статические RAW изображения по выделенному интерфейсу, то fps наверное была постоянна.

[dadreamer]

Если используется IMAQdx Get Image VI с параметром Buffer Number Mode = Next (дефолт), то драйвер сам ждёт, пока кадр попадёт в буфер, поэтому дополнительные задержки не нужны.
Buffer Number Mode (Next) specifies the buffer number mode. The default value is Next, which specifies that the driver will wait for the next acquired buffer. Other possible values are Last, which specifies that the driver will not wait for the next buffer but will instead return the last acquired buffer, and Buffer Number, which specifies an exact buffer number to wait for. Use Buffer Number Mode in conjunction with Buffer Number In.
https://documentation.help/NI-IMAQdx-VI ... Image.html
Ну, и надо учитывать, что у вас не RTOS, поэтому возможен джиттер порядка 10-15 мс. При частоте передачи кадров 25 fps у вас 1 кадр поступает каждые 40 мс, при частоте 30 fps - каждые 33 мс. Цикл должен в идеале забирать данные немного быстрее, чем они приходят, иначе будут потери или накопления. Также может влиять ещё множество факторов, как уже было отмечено. Например, если у вас камера подключена через свитч, а в него ещё какое-то сетевое оборудование подключено, другие камеры. Попробуйте прямое подключение через гигабитный интерфейс. Ситуация должна стать лучше.

[rushonda]

В общем проверил все на ethernet камере, подключенной непосредственно к сетевой плате, график получился примерно такой же.

[dadreamer]

rushonda, а если подключаться по rtsp через VLC? И насколько критична плавающая частота?.. Обычно для алгоритмов машинного зрения fps - маловажный фактор, т.к. не требуется постоянно получать и обрабатывать изображение. Скажем, раз в несколько секунд взяли кадр, обработали/проанализировали и ждём, изображение с камеры выводится просто для наблюдения. Если, конечно, машинное зрение не является частью какой-то критически важной системы. Но в таком случае нужно сразу строить ПО на ОС реального времени.

[rushonda]

dadreamer, нужно обрабатывать каждый кадр с камеры. Нет примера подключения по rtsp через VLC, или ссылки на пример?
Про ПО на ОС реального времени, не факт что это не с камерой связано, возможно камера так кадры отдает. или не так?

[dadreamer]

Нет примера подключения по rtsp через VLC, или ссылки на пример?
Это пример для 32-битного : viewtopic.php?p=63217#p63217
А это для 64-битного: viewtopic.php?p=79814#p79814
Для большей уверенности нужно почитать маны к камере и понять, может ли она отдавать в rtsp. Потому что не все камеры это умеют.
Про ПО на ОС реального времени, не факт что это не с камерой связано, возможно камера так кадры отдает. или не так?
Я больше склоняюсь к тому, что это из-за использования IMAQdx в режиме поллинга (непрерывный опрос) + jitter ОС. Меня ещё вот что смущает у вас на БД: Hi Res Relative Seconds выполняется параллельно с IMAQdx Get Image, т.е. теоретически сперва может быть выполнен один , затем другой, на следующей итерации наоборот, ещё дальше - сразу оба и т.д. Надо жёстко зафиксировать измерение таймера относительно IMAQdx Get Image (например, с помощью Sequence Structure). Измерьте также и выведите на график время выполнения IMAQdx Get Image. Посмотрим, что получится.

Да, и было бы интересно увидеть маркировку видеокамеры.

[rushonda]

Меня ещё вот что смущает у вас на БД: Hi Res Relative Seconds выполняется параллельно с IMAQdx Get Image, т.е. теоретически сперва может быть выполнен один , затем другой, на следующей итерации наоборот, ещё дальше - сразу оба и т.д. Надо жёстко зафиксировать измерение таймера относительно IMAQdx Get Image (например, с помощью Sequence Structure). Измерьте также и выведите на график время выполнения IMAQdx Get Image. Посмотрим, что получится.
Да, и было бы интересно увидеть маркировку видеокамеры.

Если сделать измерение частоты как Вы говорите в Sequence Structure после получения кадра, график не меняется.
На всех камерах на которых пробовал нет строгой частоты. Например basler ace 640-100gm или basler acA2000-50gm. В режиме ROI частота пляшет сильнее.
Картинки сделаны на встроенной камере ноутбука HP HD Camera. на других камерах плюс минус такие же графики.

[rushonda]

Вы дали ссылку на пример для загрузки видео из сети: это пример для 32-битного : viewtopic.php?p=63217#p63217
А подцепить камеру это целая история или все просто?

[dadreamer]

Вы дали ссылку на пример для загрузки видео из сети: это пример для 32-битного : viewtopic.php?p=63217#p63217
А подцепить камеру это целая история или все просто?
Просто замените адрес на rtsp или в чём камера отдаёт. Можно и на этом примере проверить: rtsp://wowzaec2demo.streamlock.net/vod/ ... y_115k.mov Или сперва в VLC открыть поток, если будет показывать, то и в должно всё работать.
на других камерах плюс минус такие же графики.
Ну, по-видимому, это особенность IMAQdx. Некоторые кадры удаётся забрать быстрее. Но я честно не считаю это проблемой. У вас же fps ниже 20 не падает?.. А баслеровские камеры от 20 как раз и отдают.

[rushonda]

Просто замените адрес на rtsp или в чём камера отдаёт. Можно и на этом примере проверить: rtsp://wowzaec2demo.streamlock.net/vod/ ... y_115k.mov Или сперва в VLC открыть поток, если будет показывать, то и в должно всё работать.
Ну, по-видимому, это особенность IMAQdx. Некоторые кадры удаётся забрать быстрее. Но я честно не считаю это проблемой. У вас же fps ниже 20 не падает?.. А баслеровские камеры от 20 как раз и отдают.

По поводу rtsp можно поконкретнее, какой адрес использовать для камеры, которая подключена через сетевую плату ethernet, просто ip ее забить?

В этом то и дело, что скорость падает с 30 до 20 скачками.

[dadreamer]

По поводу rtsp можно поконкретнее, какой адрес использовать для камеры, которая подключена через сетевую плату ethernet, просто ip ее забить?
Не совсем так, нужно сначала определить полный адрес потока, т.к. он для каждой камеры свой. Не факт, что это будет rtsp, может и обычный http. Используйте программу iSpy для поиска адреса, см. рекомендации в первом посте: viewtopic.php?f=22&t=7379
Адрес может получиться примерно такой: rtsp://<camera ip address>/mpeg4 или rtsp://<camera ip address>/h264?multicast , а может какой-то другой, с этим надо поиграться. Может и вообще не удастся найти адрес, если камера не транслирует сжатый поток (MPEG4, H.264; в мануале, кстати, про это ни слова). В таком случае остаётся только юзать GigE интерфейс через IMAQdx, Pylon SDK или какие-то другие пакеты, поддерживающие GigE Vision / GenICam.

[Borjomy_1]

Загрузку процессора, особенно по ядрам, смотрели? Это первое. Второе. Производительность камеры, в частности алгоритма сжатия, сильно зависит от статичности картинки. Особенно заметно на старых матрицах, но запущенных на больших разрешениях.
Тот же ffmpeg неконтролируемо пропускает кадры, если потоку не хватает мощности процессора.
Снижайте разрешение.