Pull to refresh

Comments 17

Пока планирую про стандарт. После, хотел привести пример доступной реализации камеры в коде и железе. Библиотеки затрону, но скорее всего, очень поверхностно.
Никак, это разные стандарты. На базе GenICam работают системы машинного зрения, а ONVIF предназначен для IP-камер.
Понятно, спасибо. Сходу было не очевидно.

Уважаемый Автор!
Вы пишите :"Помимо усиления используются и другие опции если это позволяет электроника. GenApi необходим для описания функционала камеры и ее параметров, например, ширины и высоты кадра в пикселях".


В этой связи прошу сообщить, является ли в GenApi "конфигурирование камер" статической или может изменяться от кадра к кадру?
Например позволяет ли данный или иной модуль совместно со специальной камерой на одном кадре строить BMP кадр -отображение прямоугольного изображения всего поля зрения объектива камеры с определенной угловой разрешающей способностью, оцифровывать и отправлять по одному адресу, а в следующем кадре BMP выводить только небольшую прямоугольную часть изображения с заданными угловыми координатами его центра и отправлять следующий кадр на другой адрес.
Затем снова BMP кадр всего поля зрения объектива ..., затем ВМР кадр небольшой части изображения с новыми угловыми координатами центра этой части?

Если следовать стандарту, а ему лучше следовать, то задача в примере будет решена неверно.
Каждая посылка видеоданных содержит в себе, помимо самих видеоданных, заголовок и окончание пакета.
В них имеется информация о кадре, который отправляется в хост.
После того, как хост даст команду, разрешающую потоковую передачу, заголовок и окончание пакета изменить будет
уже нельзя. Их можно будет изменить только после окончания приема данных и выдачи хостом сигнала остановки.
Потребуется время на изменение информации о кадре и, возможно, за это время начнется новый кадр, который будет пропущен. Если нет требования в неразрывности потока в котором выделяется окно интереса, то такой вариант подойдет. На счет разных адресов. Как я понял это адреса буферов в памяти компьютера.
Разные буфера, теоретически, сделать можно, но тут нужно углубиться в GenTL, а я, к сожалению, занимаюсь только аппаратной частью камеры и прошивкой контроллера USB.
Каждая посылка видеоданных содержит в себе, помимо самих видеоданных, заголовок и окончание пакета.
В них имеется информация о кадре, который отправляется в хост.

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

С одной стороны, у интерфейса GenTL есть понятие Stream, которое означает что камера способна отсылать более чем один поток изображений, и, наверное, в теории, можно настроить камеру так как вы сказали.
Вопрос лишь в том, найдется ли такая камера, которая это будет поддерживать… честно, я таких камер не знаю, хотя в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке (но тут получатель был один). На сколько это было успешно — не знаю.
Так же, в стандарте GEV (и скорее всего U3V, я просто его изнутри не копал) с каждым кадром приходит header и trailer которые сообщают размер, смещение, формат пикселя, временнУю метку и прочее для каждого кадра.
Соответственно в общем случае, размер кадра не фиксирован, и может изменяться (ну вы понимаете, куда вас пошлют лентяи программисты, которых заставят отслеживать размер каждого кадра и менять выходной канал в соответствии с новым кадром :) ) — но это в пределах одного потока, который приходит по одному адресу (хотя в GEV никто не запрещает этому адресу быть Broadcast или Multicast).
в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке

Как бы узнать результаты работы. Вдруг успешно?

Быстрый поиск по открытой документации на сайте производителя показал только CameraLink камеру.
Цитата из документации:
The dual video mode allows two independent acquisition
frames (Frame A and Frame B) to be programmed with independent control of exposure
time, area of interest (AOI), subsampling, gain, offset and wide dynamic range parameters.


То есть с «железной» точки зрения задача решена… только вот «заданное разрешение» задается все таки до начала захвата… вернее задать-то можно когда угодно, только вот когда желаемый кадр придет?
И еще уточняющий вопрос, указаные в вашем вопросе изменяемые параметры, это, как я понимаю AOI (Area of interest — OffsetX, OffsetY, Width, Height). Вас только AOI интересует или просто первый пришедший на ум параметр?
Если только AOI — то тогда, в общем случае, не вижу необходимости заморачиваться, проще в такой задаче получить полный кадр и дальше программно работать только с заданым подкадром.

В первой части моего сообщения выражаю Вам благодарность за ссылку, по которой пройду немедленно после получения доступа к "безлимитному Интернету".
В отношении вопроса, то ответ -конечно меня интересует "область интереса" (AOI).
Это одна из двух задач.
Однако идти по более простому варианту получения видео изображения "области интереса" из полного кадра мне, в свете рассматриваемой статьи, не интересно.
Дело в том, что по моим прогнозам площадь "области интереса" менее 5% от площади всего изображения. Поэтому мне привлекательнее сократить время считывания "области интереса" непосредственно камерой по сравнению со временем считывания полного кадра в 20 раз.
В этом я предполагаю будет гешефт. который можно будет использовать.
Конечно, если мне не удастся найти соответсвующую камеру, купить и настроить, то придется идти по Вами предложенному пути.

Не могу говорить о GigE Vision и CameraLink, т.к. работаю с USB3. При инициализации хостом устройства на USB, хост, в том числе, запрашивает параметры канала передачи видеоданных. Создаются так называемые эндпоинты(конечные точки). У хоста имеется свой эндпоинт(точка) и у устройства, а между ними создается канал передачи. В дескрипторе, который описывает эндпоинт четко зафиксирован максимальный размер данных, который может быть передан устройством в рамках одной посылки. Вам необходимо переключаться от вывода полного кадра к выводу только области интереса. Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту. Проще всего не менять настройки эндпоинта и продолжать принимать полный кадр с последующей обработкой на хосте. Либо, изначально определиться с размером области интереса и настроить передачу под нужные параметры и выводить только AOI.
Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту.

Эм… может я конечно что-то в чем-то не понимаю (как я говорил, я U3V не копал), но мне кажется это неправильным и нелогичным — а если мы хотим поменять разрешение кадра? Это что же, перегружать камеру? А значит терять тщательно подобранные параметры камеры (например время экспозиции и настройки триггера)?
Исходя из того, что я вижу в наших исходниках — хост и камера договариваются об аналоге MTU, и дальше камера передает Leader + N*MTU + FinalTransfer + Header, из которых и собирается кадр.

Ну вот, собственно и подтверждение: www.visiononline.org/userAssets/aiaUploads/file/USB3_Vision_Specification_v1-0-1.pdf (не исключаю что старый, просто первый попавшийся в гугле)
5.2 Streaming Mechanism
5.2.3 Payload Sequence
The SI Payload Transfer Size, SI Payload Transfer Count and SI Payload Final Transfer1
Size and SI Payload Final Transfer2 Size registers describe the host´s requirements
concerning payload data layout. If the device has less payload data to send than expected by the
host it must complete the outstanding transfer(s) using short or zero-length packets.
The payload is divided into “equal sized blocks” + “final transfer1”+ “final transfer2”.
Properties of “equal sized blocks” are described by SI Payload Transfer Size and SI Payload
Transfer Count.
The maximum size of payload data in bytes the device may send can be calculated as follows:
maximum_size_of_payload_data_in_bytes = SI Payload Transfer Size * SI Payload Transfer
Count + SI Payload Final Transfer1 Size + SI Payload FinalTransfer2 Size


Таким образом, изменение размера кадра ведет к изменение TransferCount и FinalTransferSize 1/2, но никак не перезагрузке USB
Речь идет именно об оптимизации потока.
Поэтому мне привлекательнее сократить время считывания «области интереса» непосредственно камерой по сравнению со временем считывания полного кадра в 20 раз.

Если область интереса умещается в один буфер эндпоинта и там остается свободное место, то, при необходимости оптимизации передачи данных, следует поменять настройки эндпоинта и прикрепленных к нему буферов для того, чтобы не передавать лишние байты. Но если в оптимизации потребностей нет, все остается как есть и AOI будет собираться с лишними байтами в буферах — Leader + Payload + Trailer. Конечно же перезагрузка камеры логически не укладывается в GenICam.
Можно сказать, что это пример подстройки канала передачи под AOI для оптимизации потока. Необходимо изначально выбрать удобный размер эндпоинта, т.к. для изменения его настроек в самом простом случае следует изменить прошивку контроллера для работы с новыми параметрами. А это, как понимаете, вообще неудобно.

GenTL это всё-таки Transport Layer.
GenICam, как стандарт, описывает только формат xml файла который определяет, по какому регистру лежит тот или иной параметр.
Так же среди прочих "модулей" вы не назвали модуль PFNC, без которого прием и передача изображения была бы не возможна, но, как и SFNC это только список рекомендаций по именованию параметров.
Ещё есть огромный недостаток в полной не связанности модулей GenTL и GenICam, и, зачастую, оторванности стандартов U3V, GEV и CameraLink друг от друга…
Хотя CameraLink он вообще не от мира сего… Стандарт который описывает только физику, а про программное обеспечение они практически забили.

Sign up to leave a comment.

Articles