Не будут. Для примера можно посмотреть мой родной г.Королев, в котором 4 улицы Горького, две улицы Калининградская, и, самое веселое, две улицы пушкинская соединяющиеся в одной точке ( yandex.ru/maps/20728/korolev/?ll=37.843171%2C55.932928&z=18 ) практически по диагонали стоит два дома по адресу ул. Пушкинская д.13, только один в мкр. Болшево, а второй мкр. Юбилейный, который раньше был городом Юбилейный.
Не-е-е… это не наш метод! Надо сначала 10%+1000 р., а потом «внимательно выслушав избирателей», с широкого барского плеча снизить до 3% + 300 р. — И все! Народ доволен! Правительство хорошее!
Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту.
Эм… может я конечно что-то в чем-то не понимаю (как я говорил, я U3V не копал), но мне кажется это неправильным и нелогичным — а если мы хотим поменять разрешение кадра? Это что же, перегружать камеру? А значит терять тщательно подобранные параметры камеры (например время экспозиции и настройки триггера)?
Исходя из того, что я вижу в наших исходниках — хост и камера договариваются об аналоге MTU, и дальше камера передает Leader + N*MTU + FinalTransfer + Header, из которых и собирается кадр.
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
И еще уточняющий вопрос, указаные в вашем вопросе изменяемые параметры, это, как я понимаю AOI (Area of interest — OffsetX, OffsetY, Width, Height). Вас только AOI интересует или просто первый пришедший на ум параметр?
Если только AOI — то тогда, в общем случае, не вижу необходимости заморачиваться, проще в такой задаче получить полный кадр и дальше программно работать только с заданым подкадром.
Быстрый поиск по открытой документации на сайте производителя показал только 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.
То есть с «железной» точки зрения задача решена… только вот «заданное разрешение» задается все таки до начала захвата… вернее задать-то можно когда угодно, только вот когда желаемый кадр придет?
С одной стороны, у интерфейса GenTL есть понятие Stream, которое означает что камера способна отсылать более чем один поток изображений, и, наверное, в теории, можно настроить камеру так как вы сказали.
Вопрос лишь в том, найдется ли такая камера, которая это будет поддерживать… честно, я таких камер не знаю, хотя в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке (но тут получатель был один). На сколько это было успешно — не знаю.
Так же, в стандарте GEV (и скорее всего U3V, я просто его изнутри не копал) с каждым кадром приходит header и trailer которые сообщают размер, смещение, формат пикселя, временнУю метку и прочее для каждого кадра.
Соответственно в общем случае, размер кадра не фиксирован, и может изменяться (ну вы понимаете, куда вас пошлют лентяи программисты, которых заставят отслеживать размер каждого кадра и менять выходной канал в соответствии с новым кадром :) ) — но это в пределах одного потока, который приходит по одному адресу (хотя в GEV никто не запрещает этому адресу быть Broadcast или Multicast).
GenTL это всё-таки Transport Layer.
GenICam, как стандарт, описывает только формат xml файла который определяет, по какому регистру лежит тот или иной параметр.
Так же среди прочих "модулей" вы не назвали модуль PFNC, без которого прием и передача изображения была бы не возможна, но, как и SFNC это только список рекомендаций по именованию параметров.
Ещё есть огромный недостаток в полной не связанности модулей GenTL и GenICam, и, зачастую, оторванности стандартов U3V, GEV и CameraLink друг от друга…
Хотя CameraLink он вообще не от мира сего… Стандарт который описывает только физику, а про программное обеспечение они практически забили.
Вот, кстати, где физическое вступление было нужным и ненужным одновременно (и его наличие было причиной отказа моей жены-гуманитария от чтения этого великого произведения) — Сами Боги, Айзека Азимова.
Возник вопрос по поводу первой утечки памяти…
Вполне вероятно (код не читал) классы Beam и MasterScore являются наследниками QObject (тут же у нас Qt код), а значит при создании экземпляра класса Beam в список "детей" MasterScore'а записывается этот экземпляр, который будет удалён по удалению "отца", а значит утечки не будет.
Хотя в любом случае код является "подозрительным".
Телевизор не смотрю, новостные сайты читаю очень-очень редко. Довольно часто случается ситуация что о последних новостях узнаю из 'bash.im'. Ну иногда заглядываю в GoogleNow
А можно пояснить вот этот момент из пункта про DKIM:
Но что если данные MTA окажутся скомпрометированными, и злоумышленник также получит возможность отправлять поддельные письма через эти серверы? Как установить подлинность отправителя в этом случае? На помощь приходит аутентификация писем.
Сервер отправитель формирует отпечаток заголовков письма с помощью хэш-функции и подписывает его, используя закрытый ключ.
А Сервер-отправитель (то есть поле smtp server в настройке моего почтового клиента) и MTA это разве не одно и тоже лицо?
Тут мало того что город, так нет ни улицы ни номера дома… только номер корпуса…
Эм… может я конечно что-то в чем-то не понимаю (как я говорил, я U3V не копал), но мне кажется это неправильным и нелогичным — а если мы хотим поменять разрешение кадра? Это что же, перегружать камеру? А значит терять тщательно подобранные параметры камеры (например время экспозиции и настройки триггера)?
Исходя из того, что я вижу в наших исходниках — хост и камера договариваются об аналоге MTU, и дальше камера передает Leader + N*MTU + FinalTransfer + Header, из которых и собирается кадр.
Ну вот, собственно и подтверждение: www.visiononline.org/userAssets/aiaUploads/file/USB3_Vision_Specification_v1-0-1.pdf (не исключаю что старый, просто первый попавшийся в гугле)
Таким образом, изменение размера кадра ведет к изменение TransferCount и FinalTransferSize 1/2, но никак не перезагрузке USB
Если только AOI — то тогда, в общем случае, не вижу необходимости заморачиваться, проще в такой задаче получить полный кадр и дальше программно работать только с заданым подкадром.
Цитата из документации:
То есть с «железной» точки зрения задача решена… только вот «заданное разрешение» задается все таки до начала захвата… вернее задать-то можно когда угодно, только вот когда желаемый кадр придет?
Вопрос лишь в том, найдется ли такая камера, которая это будет поддерживать… честно, я таких камер не знаю, хотя в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке (но тут получатель был один). На сколько это было успешно — не знаю.
Так же, в стандарте GEV (и скорее всего U3V, я просто его изнутри не копал) с каждым кадром приходит header и trailer которые сообщают размер, смещение, формат пикселя, временнУю метку и прочее для каждого кадра.
Соответственно в общем случае, размер кадра не фиксирован, и может изменяться (ну вы понимаете, куда вас пошлют лентяи программисты, которых заставят отслеживать размер каждого кадра и менять выходной канал в соответствии с новым кадром :) ) — но это в пределах одного потока, который приходит по одному адресу (хотя в GEV никто не запрещает этому адресу быть Broadcast или Multicast).
GenTL это всё-таки Transport Layer.
GenICam, как стандарт, описывает только формат xml файла который определяет, по какому регистру лежит тот или иной параметр.
Так же среди прочих "модулей" вы не назвали модуль PFNC, без которого прием и передача изображения была бы не возможна, но, как и SFNC это только список рекомендаций по именованию параметров.
Ещё есть огромный недостаток в полной не связанности модулей GenTL и GenICam, и, зачастую, оторванности стандартов U3V, GEV и CameraLink друг от друга…
Хотя CameraLink он вообще не от мира сего… Стандарт который описывает только физику, а про программное обеспечение они практически забили.
На сколько я помню, фраза была "звезда умерла, чтобы ты могла носить это кольцо" (говорится тоном защитников животных и прочих веганов)
Возник вопрос по поводу первой утечки памяти…
Вполне вероятно (код не читал) классы
BeamиMasterScoreявляются наследникамиQObject(тут же у нас Qt код), а значит при создании экземпляра класса Beam в список "детей"MasterScore'а записывается этот экземпляр, который будет удалён по удалению "отца", а значит утечки не будет.Хотя в любом случае код является "подозрительным".
А Сервер-отправитель (то есть поле smtp server в настройке моего почтового клиента) и MTA это разве не одно и тоже лицо?