Поэтому мне привлекательнее сократить время считывания «области интереса» непосредственно камерой по сравнению со временем считывания полного кадра в 20 раз.
Если область интереса умещается в один буфер эндпоинта и там остается свободное место, то, при необходимости оптимизации передачи данных, следует поменять настройки эндпоинта и прикрепленных к нему буферов для того, чтобы не передавать лишние байты. Но если в оптимизации потребностей нет, все остается как есть и AOI будет собираться с лишними байтами в буферах — Leader + Payload + Trailer. Конечно же перезагрузка камеры логически не укладывается в GenICam.
Можно сказать, что это пример подстройки канала передачи под AOI для оптимизации потока. Необходимо изначально выбрать удобный размер эндпоинта, т.к. для изменения его настроек в самом простом случае следует изменить прошивку контроллера для работы с новыми параметрами. А это, как понимаете, вообще неудобно.
Не могу говорить о GigE Vision и CameraLink, т.к. работаю с USB3. При инициализации хостом устройства на USB, хост, в том числе, запрашивает параметры канала передачи видеоданных. Создаются так называемые эндпоинты(конечные точки). У хоста имеется свой эндпоинт(точка) и у устройства, а между ними создается канал передачи. В дескрипторе, который описывает эндпоинт четко зафиксирован максимальный размер данных, который может быть передан устройством в рамках одной посылки. Вам необходимо переключаться от вывода полного кадра к выводу только области интереса. Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту. Проще всего не менять настройки эндпоинта и продолжать принимать полный кадр с последующей обработкой на хосте. Либо, изначально определиться с размером области интереса и настроить передачу под нужные параметры и выводить только AOI.
Если следовать стандарту, а ему лучше следовать, то задача в примере будет решена неверно.
Каждая посылка видеоданных содержит в себе, помимо самих видеоданных, заголовок и окончание пакета.
В них имеется информация о кадре, который отправляется в хост.
После того, как хост даст команду, разрешающую потоковую передачу, заголовок и окончание пакета изменить будет
уже нельзя. Их можно будет изменить только после окончания приема данных и выдачи хостом сигнала остановки.
Потребуется время на изменение информации о кадре и, возможно, за это время начнется новый кадр, который будет пропущен. Если нет требования в неразрывности потока в котором выделяется окно интереса, то такой вариант подойдет. На счет разных адресов. Как я понял это адреса буферов в памяти компьютера.
Разные буфера, теоретически, сделать можно, но тут нужно углубиться в GenTL, а я, к сожалению, занимаюсь только аппаратной частью камеры и прошивкой контроллера USB.
Пока планирую про стандарт. После, хотел привести пример доступной реализации камеры в коде и железе. Библиотеки затрону, но скорее всего, очень поверхностно.
Все вопросы, связанные с ПЗС, лучше задавать нашим разработчикам ПЗС, т.к. здесь они более компетентны чем я. У меня, к сожалению, сейчас отпуск до понедельника и я не могу у них ничего узнать. Контакты тут .
Примеры изображений есть(тест-таблицы). RGB — линеек у нас нет. На счет них можно спросить у маркетинга, может быть другие отделы этим занимаются.
С этими стандартами не работал, но у нас есть стенд с фреймграббером под определенный тип линеек (создавали до меня). Все прекрасно работает. Минус такого подхода — это необходимость наличия фреймграббера, дорого. Без него камеру к ПК не подключить, а USB 3 есть уже везде.
Продукты посмотреть можно — поддержка линеек, тут можно спросить и про матрицу 1000*1000 и основной сайт ОАО «ЦНИИ „ЭЛЕКТРОН“»
Если область интереса умещается в один буфер эндпоинта и там остается свободное место, то, при необходимости оптимизации передачи данных, следует поменять настройки эндпоинта и прикрепленных к нему буферов для того, чтобы не передавать лишние байты. Но если в оптимизации потребностей нет, все остается как есть и AOI будет собираться с лишними байтами в буферах — Leader + Payload + Trailer. Конечно же перезагрузка камеры логически не укладывается в GenICam.
Можно сказать, что это пример подстройки канала передачи под AOI для оптимизации потока. Необходимо изначально выбрать удобный размер эндпоинта, т.к. для изменения его настроек в самом простом случае следует изменить прошивку контроллера для работы с новыми параметрами. А это, как понимаете, вообще неудобно.
Каждая посылка видеоданных содержит в себе, помимо самих видеоданных, заголовок и окончание пакета.
В них имеется информация о кадре, который отправляется в хост.
После того, как хост даст команду, разрешающую потоковую передачу, заголовок и окончание пакета изменить будет
уже нельзя. Их можно будет изменить только после окончания приема данных и выдачи хостом сигнала остановки.
Потребуется время на изменение информации о кадре и, возможно, за это время начнется новый кадр, который будет пропущен. Если нет требования в неразрывности потока в котором выделяется окно интереса, то такой вариант подойдет. На счет разных адресов. Как я понял это адреса буферов в памяти компьютера.
Разные буфера, теоретически, сделать можно, но тут нужно углубиться в GenTL, а я, к сожалению, занимаюсь только аппаратной частью камеры и прошивкой контроллера USB.
Примеры изображений есть(тест-таблицы). RGB — линеек у нас нет. На счет них можно спросить у маркетинга, может быть другие отделы этим занимаются.
Продукты посмотреть можно — поддержка линеек, тут можно спросить и про матрицу 1000*1000 и основной сайт ОАО «ЦНИИ „ЭЛЕКТРОН“»