Есть задача посчитать на ПЛИС FFT от матрицы 128 на 128 (кусок видеоизображения).
Если я правильно понимаю, то для этого можно использовать уже готовое одномерное FFT (Альтеровская мегафункция).
1. Сделать FFT от каждой строки.
2. Сделать FFT от каждого столбца матрицы полученной после пункта 1.
Исходные данные имеют тип 8 бит real (яркостный канал).
Насколько я понимаю, полученный спектр будет симметричным, так что достаточно хранить только реальную часть примежуточной матрицы.
Так ли это?
И как выбрать разрядность для промежуточной матрицы?
8, 10 бит?

Идея преобразования правильная. Но вот выбрать разрядность можно, лишь зная назначение самого преобразования.

Нет. Это значит что надо хранить реальную и мнимую часть, но достаточно половины отсчётов.

Профи лучше ответят. Но насколько я понял это зависит от уровня шумов допустимых на следующем этапе обработки.
И скорее вам подойдёт 16 бит.

Сообщение отредактировал Pavia - Dec 7 2015, 19:35

Т.е. если количество точек FFT равно 128, то достаточно будет хранить отсчёты с 0 по 63?

Если Вы собрались делать полноценное двумерное Фурье, то для представления результата нужны все полученные коэффициенты. Это в ДКП возможное число коэффициентов, при некотором допущении, получается меньшим. Выкинув половину полученных коэффициентов, вы можете получить нулевой результат при полноценном исходном кадре.
Мы опять вернулись к вопросу: что ВЫ с этим двумерным Фурье потом будете делать?
Если сжимать, то берите первый jpeg (не редакции 2000 года, в нем уже вейвлеты) и читайте-там все разжевано. Только там матрица 8х8 и придется напрячься, чтобы адаптировать под ВАШИ 128х128.
Если использовать как фильтр шума, в системе распознания образов, то Фурье в данном случае инструмент непригодный и надо использовать ДДВП или ДДПУ с алгоритмом предложенным вами и округлением, которое надо подобрать на основе некоторого практического эксперимента с ВАШЕЙ библиотекой образов.

С тем, что нужно хранить все значения я теперь разобрался.
FFT нужен для того, чтобы сделать взаимную коррелляцию текущего и предыдущего кадра.
Таким образом я хочу определить смещение текущего фонового изображения относительно предыдущего.
Всё это нужно для автоматической стабилизации изображения.

Как определяют фон...
Сначала делают межкадровое вычитание. Потом делают инверсию модуля с сохранением знака, чтобы участки с малой разницей между кадрами стали максимально яркими. Это и есть фоновые участки.
Результат обрабатывают Фурье, вейвлетами или преобразованием Уолша. Тут уже для поиска движения подходят разные методы.
Сразу скажу, при такой обработке нужна максимально высокая точность и обрезать биты не рекомендуется. Для вашего случая результат будет 15 битный после строк и 22 битный после столбцов. Обрежете сильнее, на малоконтрастных изображениях начнет косячить стабилизатор.

К сожалению, просто межкадровое вычитание делать не получиться, т.к. за время одного кадра камера может повернуться весьма значительно. Хотя может быть я не до конца понял Ваш алгоритм... Если кратко описать задачу, то мне нужно получить две вещи:
1. Стабилизировать изображение движущейся камеры, причём она может вращаться как по оси X, так и по оси Y. Т.е. нужно убрать тряску которая возникает при вращении опорно-поворотного устройства.
2. Определить смещение изображения и после этого сделать межкадровое вычитание, чтобы определить координаты движущегося объекта и отцентрировать по нему видеокамеру.

Делал похожую штуку, для достижения нормальной точности пришлось перейти на 32 бит float

Информативность Вашего поста близка к нулю, это же очевидно, нэ?

И, да - поясните, что Вы подразумеваете под 32 бит float?
Неужели IEEE754 и single?
А, какую именно модель подстандарта?
Интелловскую "расслабленную" или более корректную?
А, тест «Floating point paranoia» проходили на своей платформе?
Нет?
Ну.. батенька.

Нэ



Да


Не знаю что такое расслабленная и более корректная модель)) Каюсь, понадеялся что ребята из альтеры разрулили это за меня в своем ффт мегакоре

Я понимаю краткость сестра таланта. В этой ветке делятся алгоритмами или разбираются в алгоритмах/математике.
Совет:
Ответы/посты, информативность которых сводиться к нулю, лучше просто не давайте здесь.
Если же отвечаете давайте более менее полный ответ на вопрос, чтобы было понятно другим.

Иначе в будущем можете получить на свои вопросы ответы в Вашем стиле...

Я весь алгоритм не могу расписать, т.к. алгоритм не мой, я подписывал NDA. Человек спросил про разрядность, я описал свой опыт в этом вопросе. Написал потому что если человек сделает на 16 бит все систему, то как только он начнет с реальной камерой работать, поймет что пол проекта надо переписывать. 32 битный флоат по умолчанию предполагает IEEE754, по крайней мере везде, где я с этим сталкивался, в том числе в альтервской коре, которую я использую.

Я как бы уже написал, что для обработки достаточно 22 бит. Большего разнообразия 128х128 uchar просто дать не может (максимум, плюс 14 бит). Причем, для умножения хватит родных для ПЛИС 18sx18s. То есть коэффициенты в 18 бит со знаком достаточны, а результат второго преобразования можно округлять до 22 бит. Главное, не ошибиться в том месте, где они эти 22 бита находятся!