ZhekSooN

Нет, простите. За качество ничего сказать не могу. На настоящих шумных данных с дебаером проблемка - то, что хорошо восстанавливает границы, начинает группировать шумные пиксели, а простые и быстрые алгоритмы, вроде этого, не блещут восстановлением. Ребята из публикации A case for denoising before demosaicking color filter array data приводили такой график: Быстро - в определенных случаях не значит плохо :)

Попробуйте Effective Color Interpolation in CCD Color Filter Arrays Using Signal Correlation (Soo-Chang Pei, Fellow, IEEE, and Io-Kuong Tam), там даже умножений нету :)

Да, основная гармоника изменяется от Fs/6 до Fs/4 (максимум - Fs/2). :) Собираюсь в универе сделать докладик по фрактальным свойствам этой штуки, вдруг что найду интересное ;)

Звучит плохо, зато выглядит как! :rolleyes:

Всем добрый день! Подкиньте пожалуйста код на паскале-подобном языке, как совместить две веществнных последовательности в одну комплексную, и как их разделить после Фурье. Заранее благодарю.

sup-sup, но это же все тогда, когда отфильтровано все, что выше F/2 - а это совсем не мой случай.

Спасибо всем за развернутые ответы, но чувствую, что от цифровой децимации придется отказаться, так как для нормальных характеристик это будет сравнимо по сложности с самим БПФ, которое тоже будет выполнятся на МК. Проще уж переключать входы/скорость АЦП и сделать аналоговый фильтр (все равно АРУ понадабится), чем тратить половину времени и памяти на обработку "быстрых" выборок.

Он-то хорош, но сильно много таблиц выходит, да и коэффиценты на порядки отличаются в различных местах - на МК AVR будет тяжко...

Да, спасибо, не заметил - сразу наложил скользящее среднее на такое усреднение. Да, будет именно "обработка" звука на МК - чтобы не переключать АЦП на более низкую частоту отсчетов (надо получать семплы с большой и с маленькой частотой дискретизации) и не городить аналоговые фильтры. Требования сильные не нужны - чтобы у ресемплированого сигнала был реалистичный спектр. Может есть другие хорошие способы? (восьмибитная арифметика и минимум промежуточных данных приветствуются)

Так при моем усреднении даже и этого плавающего среднего не будет, к примеру при k=5 первая выборка результата будет определяться так: b[1]=(a[1]+a[2]+a[3]+a[4]+a[5])/5 , вторая - b[2]=(a[6]+a[7]+a[8]+a[9]+a[10])/5 , то есть вторая никак не зависит от предыдущих отсчетов. А в плавающем среднем будет зависеть.

Так вроде это сильно, очень сильно будет вонять ализингом... Тем более что коэффицент децимации что-то около 20-40.

Короче говоря вопрос в чем: можно ли уменьшать частоту дискретизации в целое кол-во раз просто усредняя N отсчетов и выдавая его за один? Не будет ли сильного ализинга?

Урррааа!Я нашел проблему - она крылась в коде двоично-инверсной перестановки. Поменял этот участок на заведомо рабочий - все заработало как надо! Благодарю всех за участие в обсуждении.

Ну, в первую очередь меня интересует алгоритм, а не результат. Во-вторых, он будет переписываться на ассембелере для AVR и экстримально оптимизироваться, так что мне ну никак не подходят реализации с любой оптимизацией (как, например, от ivan219) под конкретные условия (в алгоритме ivan219 задумывалось, что взятие синуса будет долгим, вот и оптимизировалось). В алгоритме от Сато нету ни капли лишней воды, но он не работает :( Вот поэтому и пытаюсь найти ошибку, а не беру готовую либу (кстати, такие есть и для AVR, но хочется сделать лучше :) ).

Спасибо, алглибовские сырцы уже смотрел, но в первую очередь инетерсуюсь прозрачными "монолитными" алгоритмами без лишнего мусора в виде кучи функций и заточки под определенный язык. :smile3046: