Этот пример показывает, как ввести нарушения в порядке протестировать проект с несовершенным вводом видео. При разработке алгоритмов обработки видеоданных важное беспокойство является качеством входящего видеопотока. Реальные системы видео, как камеры наблюдения или видеокамеры, производят несовершенные сигналы. Поток может содержать ошибки, такие как активные строки неравной длины, незначительных сбоев или неполных кадров. В симуляции источник потокового видео будет обычно производить совершенные сигналы. Когда вы используете блок Frame To Pixels от Vision HDL Toolbox™, все строки имеют равный размер, и все кадры завершены. Видео алгоритм, который моделирует хорошо при этих условиях, не гарантирует своей эффективности на FPGA, который соединяется с реальным источником видеосигнала. Чтобы оценить робастность видео алгоритма под неидеальными реальными видеосигналами, это практично, чтобы ввести нарушения в пиксельном потоке.
Этот пример расширяет пример Наложения Обнаружения и Изображения Ребра путем ручного маскирования от ведущих управляющих сигналов кадра напомнить сценарий, где алгоритм запускается посреди кадра. Такие сценарии тестирования необходимы, чтобы доказать робастность проектов потокового видео.
Это выгодно, чтобы пробежаться через пример Наложения Обнаружения и Изображения Ребра прежде, чем перейти к этому примеру.
Структуру примера EdgeDetectionAndOverlayWithImpairedFrameHDL.slx показывают ниже, который тесно следует за структурой блока обработки пиксельного потока модели в Наложении Обнаружения и Изображения Ребра.
Подсистема Обнаружения Ребра реализует алгоритм Sobel, чтобы подсветить ребро изображения. Выровнять Видео подсистема используется, чтобы синхронизировать задержанный вывод EdgeDetector с исходным кадром. Отобразите веса Наложения, и подводит итог двух выровненных временем изображений.
Этот материал организован можно следующим образом. Мы сначала разрабатываем Выровнять Видео подсистему, которая работает хорошо с совершенными видеосигналами. Затем мы используем подсистему Нарушения Кадра для маски от ведущих управляющих сигналов кадра напомнить сценарий, где алгоритм запускается посреди кадра. Мы будем видеть, что такое нарушение делает, Выравнивают неэффективное Видео. Наконец, исправленная версия Выравнивается, Видео разрабатывается, чтобы решить проблему.
Выровняйтесь Видео реализовано как различная подсистема. Можно использовать переменную VERSION в рабочей области, чтобы выбрать, какую из этих двух версий вы хотите моделировать.
Примечание: Начиная в R2017a блок Pixel Stream Aligner заменяет Выровнять Видео подсистему, показанную здесь. Этот новый блок устанавливает настройку buffer size строки и количество намного легче строк и генерирует HDL-код. В новых проектах используйте блок Pixel Stream Aligner, а не Выровнять Видео подсистему. Для примера того, как использовать блок, смотрите Наложение Обнаружения и Изображения Ребра.
Следующая схема показывает структуру первой версии Выровнять Видео подсистемы.
Выровняйтесь Видео использует управляющие сигналы обнаружить активную область кадра. Для получения дополнительной информации о пиксельном протоколе потоковой передачи смотрите Пиксельный Интерфейс Потоковой передачи.
Основная идея выровнять потоки на два пикселя состоит в том, чтобы буферизовать допустимые пиксели, которые прибывают ранее в FIFO, базирующийся только на допустимых сигналах, и соответственно выталкивают отдельный пиксель от этого FIFO на основе допустимого сигнала задержанного пиксельного потока.
Чтобы проиллюстрировать, как подсистема Нарушения Кадра работает, рассмотрите 2 3 пиксельный кадр. В фигуре ниже, этот кадр, показал в пунктирном прямоугольнике с неактивными пикселями, окружающими его. Неактивные пиксели включают заднее крыльцо 1 пиксель шириной, передний подъезд 2 пикселя шириной, 1 строка перед первой активной строкой и 1 строкой после последней активной строки. И активные и неактивные пиксели маркированы своими полутоновыми значениями.
Если блок Frame To Pixels признает, что это 2 3 структурирует как вход, и его настройки соответствуют длинам подъезда, показанным выше, то схема синхронизации Frame To Pixels вывод проиллюстрирована в верхней половине следующей схемы.
Подсистема Нарушения Кадра пропускает конфигурируемое количество допустимых пикселей в начале симуляции. Например, если бы это было сконфигурировано, чтобы пропустить 4 пикселя кадра в качестве примера, результат был бы как в более низкой половине схемы синхронизации. Мы видим, что путем пропуска 4 допустимых пикселей, три допустимых пикселя на второй строке (т.е. со значениями интенсивности 30, 60, и 90), и первый допустимый пиксель на третьей строке, маскируются прочь, наряду с их связанными управляющими сигналами. Кроме того, подсистема Нарушения Кадра вводит две тактовых задержки. Если мы вводим 0 пикселей, чтобы пропустить, это только задерживает и пиксель и ctrl выходные параметры от Кадра До Пикселей двумя тактами.
Дважды кликните подсистему Нарушения Кадра и гарантируйте, что 'Номер допустимых пикселей, чтобы пропустить' определяется к 0. Как упомянуто прежде, эта установка не повреждает кадр, все, что это делает должен задержать и пиксель и ctrl выходные параметры от Кадра До Пикселей двумя тактами. Вывод от видеовыхода показывают ниже, который ожидается.
Теперь, дважды кликните Нарушение Кадра снова и введите любой положительный целый номер, скажите 100 в поле 'Number of valid pixels to skip'.
Повторно выполните модель, и получившийся видеовыход показывают ниже.
Мы видим, что ребро, которое вывод в нужной области кадра, но оригинальное изображение переключено. Этот вывод ясно предлагает, чтобы наша первая версия Выровнялась, Видео не устойчиво против пиксельного потока, который запускается посреди кадра.
Две причины объясняют это поведение. Во-первых, блок EdgeDetector начинает обрабатывать только после наблюдения, что допустимый кадр запускается, обозначенный hStart, vStart, и допустимым движением высоко в том же такте. Блок ничего не выводит для частичного кадра. Во-вторых, FIFO, в Выровнять Видео подсистеме, начинает буферизовать кадр, если допустимый сигнал верен, является ли это частичным кадром или полным кадром. Поэтому в начале второго кадра, FIFO был загрязнен пикселями предыдущего частичного кадра.
На основе понимания, полученного от предыдущего раздела, Выравнивается исправленная версия, Видео показывают ниже.
Цель состоит в том, чтобы только продвинуть пиксели полных кадров в FIFO. Если ведущие кадры не завершены, их допустимые пиксели проигнорированы.
Чтобы достигнуть этого, названная блокировка активированного регистра используется (подсвеченный в схеме выше). Его начальное значение является логическим нолем. Выполнение операции "И" этот 0 с задержанной версией допустимых всегда дает логический ноль. Это препятствует тому, чтобы любые допустимые пиксели были продвинуты в FIFO. Блокировка переключает свой вывод от логического ноля до 1 только, когда hStart, vStart, и допустимые сигналы утверждают высоко, индикатор запуска нового кадра. После переключателей блокировки к 1, вход 'нажатия' FIFO теперь следует за задержанной версией допустимого сигнала. Таким образом, допустимые пиксели нового кадра будут буферизованы в FIFO.
Чтобы протестировать эту пересмотренную реализацию, введите следующую команду в посдказке MATLAB.
VERSION=2;
Повторно выполните симуляцию. Теперь ребро вывод и оригинальное изображение отлично выравнивается.
