Чи справедливо збільшувати амплітуду (і, мабуть, якість FFT), просто масштабуючи дані?


10

Я використовую версію "KISS FFT" від Марка Боргердінга. Він приймає масив 16-бітових вхідних значень з фіксованою точкою і виробляє 32-бітний матричний результат з плаваючою точкою.

Я виявив, що якщо амплітуди введення низькі, багато значень результатів поплавця виходять нульовими, але якщо я просто масштабувати входи (скажімо, коефіцієнт 16), то менше вихідних значень дорівнюватиме нулю, і тому, здається, вихід містить більш детально. (Мало того, що це важливо для моїх цілей, але для послідовності я потім ділю отримані значення поплавця на той же коефіцієнт масштабування.)

У будь-якому випадку це, здається, спрацьовує, з точки зору отримання результату, коли раніше я тільки що отримав буфер практично всіх нулів, але мені цікаво, чи є якась причина, що це не може бути правильним підходом.

(Зауважте, що цей підхід означає, що є набагато більше "грубості" / деталізації даних, і, зокрема, низького рівня шуму, який зазвичай присутній, немає. Мені майже цікаво, чи було б розумно вводити деякий низький рівень шуму для заміни нульових значень на вході.)


"Мені майже цікаво, чи було б розумно вводити шум низького рівня для заміни нульових значень на вході." = en.wikipedia.org/wiki/Dither
ендоліт

Відповіді:


7

Це може бути правильним підходом. Ви спостерігаєте дуже практичну проблему, яка часто виникає при використанні арифметики з фіксованою точкою (тобто цілочисельною) (хоча це може траплятися і в плаваючій точці). Коли числовий формат, який ви використовуєте для виконання обчислень, не має достатньої точності, щоб виразити весь діапазон значень, які можуть випливати з ваших обчислень, потрібна певна форма округлення (наприклад, усічення, округлення до найближчого тощо) на). Це часто моделюється як додаткова помилка квантування до вашого сигналу.

Однак для деяких комбінацій алгоритму та схеми округлення, коли величина вхідного сигналу дуже низька, можна отримати те, що ви спостерігали: велика кількість нульових виходів. В основному десь у послідовності операцій проміжні результати стають досить малі, щоб не порушити поріг, необхідний для квантування до ненульового рівня. Потім значення округляється до нуля, що часто може поширюватися вперед до виходу. Результатом є, як ви зазначали, алгоритм, який генерує безліч нульових даних.

То чи можна обійти це шляхом масштабування даних? Іноді (дуже мало техніки, яка працює весь час!). Якщо ваш вхідний сигнал обмежений за величиною нижче значення, повного масштабу цифрового формату (16-бітові цілі числа працюють від -32768 до +32767), ви можете масштабувати вхідний сигнал до більш повного використання діапазону, доступного для це. Це може допомогти пом’якшити наслідки помилки округлення, оскільки величина будь-якої помилки обрізання стає меншою порівняно із сигналом, що цікавить. Так, у випадку, коли всі ваші виходи всередині алгоритму округляються до нулів, це може допомогти.

Коли така техніка може зашкодити вам? Залежно від структури обчислень алгоритму, масштабування вхідного сигналу може піддавати вас числовим переливам. Крім того, якщо сигнал містить фоновий шум або перешкоди, які за величиною більше, ніж помилка округлення алгоритму, то якість отриманого на виході типово обмежується середовищем, а не помилками, введеними в обчислення.


Я використовую динамічну техніку масштабування, яка, здається, працює досить добре. І, як би пощастило, до крайніх перехідних ситуацій все одно ставляться як до шуму і відсікаються, тому випадкові відсікання не повинні бути проблемою. Як ви вважаєте, чи правильно "зменшити масштаб" результату шляхом ділення на коефіцієнт шкали введення?
Даніель Р Хікс

1

Найпростіший і нерозумний спосіб дозволити це вирішити - перетворити дані в плаваючу точку ПЕРЕД ФФТ і використовувати плавучу точку FFT. Єдиним недоліком такого підходу було б те, що ви можете споживати більше процесора та пам'яті. Оскільки ваш вихід все одно є плаваючою точкою, практичної різниці, мабуть, мало.


Мені передали цей проект із існуючим алгоритмом FFT, який вже існує, і я зараз не бажаю з ним спілкуватися. І все це відбувається по телефону в режимі реального часу, тому продуктивність, безумовно, є проблемою.
Даніель Р Хікс

Зрозумів. Чи знаєте ви, чи внутрішній FFT є фіксованим чи плаваючою точкою? Якщо це вирішено, потрібно потурбуватися про відсікання, перелив та перелив
Гільмар

Документація та коментарі є винятковими за її відсутності, але я бачу багато вхідних кодів у коді та ще кілька дорогоцінних поплавців та дублів. Здається, вона містить грубу рамку #ifdef для переходу з 16-бітної на 32-бітну або плавучу, але рамка, очевидно, давно відключена.
Даніель Р Хікс

IPhone (процесор ARM + NEON) може робити плавучий FFT швидше (через рамку Accelerate), ніж цілий FFT в C.
hotpaw2
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.