Передать изображение в несколько циклов

[rushonda]

Добрый вечер.
Первый цикл грабит изображение с камеры.
Как максимально эффективно передать его в 3 других цикла (которые работают с разной скоростью)?
Я так понимаю, пока все циклы не обработают изображение буфер будет занят для граббинга (если конечно не создать несколько буферов для считывания кадра)
Поскольку передается не само изображение а ссылка, то есть такие варианты:

1) В основном цикле сделать 3 копии и переслать.
2) Перевести в Array и также переслать.
3) Видел на форуме Network Stream (непонятно ссылка передается или само изображение).

[zxc_pavel]

Я через очередь пиксели передаю, меня так устраивает (верхний цикл - захват, нижний - обработка)
В нижнем цикле - если в очереди что-то есть, то вытаскиваем.
В верхнем - если ничего в ней нет, то добавляем.

Это внутри grab.vi

[dadreamer]

Я тоже у себя в программах использую обычный байтовый массив (пункт 2, получается). Передаю через очереди и изредка через уведомители. Сейчас не начало 00-х, чтобы на "спичках" (т.е., на оперативке и ресурсах ЦПУ) экономить, да и картинки у меня обычно Grayscale (U8/U16), так что передаётся всё довольно быстро.

3) Видел на форуме Network Stream (непонятно ссылка передается или само изображение).

Пишут, что инструменты достаточно интеллектуальны, чтобы извлечь буфер по IMAQ-ссылке и создать внутреннюю копию для передачи. Если время будет, завтра проверю на примере.

upd: Проверил, так и есть. "Писатель" создаёт копию изображения с именем вида remote image 00000000217BA4E8 @ 1C-BD-B9-D8-11-CF pid 00001CAC. Имя уникально для одного экземпляра приложения, причём может меняться внутри самой программы в процессе её работы (об этом уже когда-то писали, только без привязки к Network Streams: viewtopic.php?p=35914#p35914 ). Если создать два канала NW Streams (т.е., две пары "читатель"-"писатель"), то иногда оба "писателя" могут брать одно и то же имя для изображения. В таком случае возможны разного рода коллизии. В общем, рекомендую передавать непосредственно массив и не заморачиваться со ссылками: https://digital.ni.com/public.nsf/allkb ... 05003F207A

[rushonda]

Я через очередь пиксели передаю, меня так устраивает (верхний цикл - захват, нижний - обработка)
В нижнем цикле - если в очереди что-то есть, то вытаскиваем.
В верхнем - если ничего в ней нет, то добавляем.
3101.png



Это внутри grab.vi
3101-1.png

Так пока очередь не освободится , я так понимаю не получится грабить новый кадр. Если очередь больше 1, то она будет расти. (я так понимаю это происходит что с image, что и с array)?

[zxc_pavel]

Я задаю максимальный размер очереди = 1.

Верхний цикл - быстрый, захват постоянно идет, просто перевод в пиксели и запись в очередь тогда, когда в очереди элементов нет.
Нижний цикл - медленный, там довольно долгая обработка изображения, в нем происходит вытаскивание из очереди.

[Borjomy_1]

Я задаю максимальный размер очереди = 1.

Верхний цикл - быстрый, захват постоянно идет, просто перевод в пиксели и запись в очередь тогда, когда в очереди элементов нет.
Нижний цикл - медленный, там довольно долгая обработка изображения, в нем происходит вытаскивание из очереди.

Вместо очереди, в таком случае, необходимо использовать Notifier

[rushonda]

Я через очередь пиксели передаю, меня так устраивает (верхний цикл - захват, нижний - обработка)

Всегда передается U32 массив, а во втором цикле опять происходит преобразование из U32 в Image?
Вы этот вариант используете что для кадров с камеры U8, что для U16 т.д. ?

В общем, рекомендую передавать непосредственно массив и не заморачиваться со ссылками: https://digital.ni.com/public.nsf/allkb ... 05003F207A

Есть ли смысл передавать не RGB в случае если изображение граббится U8 или U16 c точки зрения скорости передачи?

[Artem.spb]

Есть ли смысл передавать не RGB

есть, для сокращения потребления памяти

[dadreamer]

Есть ли смысл передавать не RGB в случае если изображение граббится U8 или U16 c точки зрения скорости передачи?

Если с камеры забирается сразу U8/U16, то зачем вообще иметь дело с U32? Выставьте везде ваше представление данных и работайте с ним. Тем более что большинство IMAQ инструментов всё равно принимают на вход U8/U16 и при подаче U32 он будет неявно преобразован.

[rushonda]

Есть ли смысл передавать не RGB в случае если изображение граббится U8 или U16 c точки зрения скорости передачи?

Если с камеры забирается сразу U8/U16, то зачем вообще иметь дело с U32? Выставьте везде ваше представление данных и работайте с ним. Тем более что большинство IMAQ инструментов всё равно принимают на вход U8/U16 и при подаче U32 он будет неявно преобразован.

[rushonda]

Есть ли смысл передавать не RGB в случае если изображение граббится U8 или U16 c точки зрения скорости передачи?

Если с камеры забирается сразу U8/U16, то зачем вообще иметь дело с U32?

Согласен с Вами. Хочу просто максимально правильно передавать изображение в другой цикл с учетом того, что формат может поменяться например с U8 на U16, тогда первый вариант не подходит (на картинке), нормально ли использовать преобразование в variant как во втором варианте?

[dadreamer]

Если формат поменяется, в любом случае придётся вносить изменения в программу:
- тип изображения у инструментов IMAQ Create;
- представления массивов-констант, задающих тип провода для сдвигового регистра/очереди/уведомителя и т.п.;
- входные и выходные терминалы у IMAQ инструментов.
Поэтому лучше заранее определиться с форматом данных. U16 - если нужна повышенная точность при обработке (например, важно нахождение границ объекта вплоть до отдельных пикселей), U8 - если такой точности не требуется. В большинстве случаев хватает U8, если "блох" / микроны ловить не собираетесь.

В variant я никогда не конвертировал и думаю, что в этом профита нет.

[rushonda]

Если формат поменяется, в любом случае придётся вносить изменения в программу:
- тип изображения у инструментов IMAQ Create;
- представления массивов-констант, задающих тип провода для сдвигового регистра/очереди/уведомителя и т.п.;
- входные и выходные терминалы у IMAQ инструментов.
Поэтому лучше заранее определиться с форматом данных. U16 - если нужна повышенная точность при обработке (например, важно нахождение границ объекта вплоть до отдельных пикселей), U8 - если такой точности не требуется. В большинстве случаев хватает U8, если "блох" / микроны ловить не собираетесь.

В variant я никогда не конвертировал и думаю, что в этом профита нет.

С подготовкой само собой - заново инициализируем буферы согласно новому типу. Как быть с тем, что в сдвиговый регистр пойдет другой тип данных (вместо U8 например U16) - как его в процессе поменять?

[dadreamer]

Как быть с тем, что в сдвиговый регистр пойдет другой тип данных (вместо U8 например U16) - как его в процессе поменять?

Тут поменяете, и провод примет новое представление. Для уверенности катушкой наводите на провод и смотрите подсказку в context help. Также следите за красными точками, точнее, за их отсутствием.

[rushonda]

Так появляется красная точка. смысл менять представление прямо в процессе работы...