Дифференцирование фильтром Савицкого-Голая

Приветствую всех!

Коротко: есть такая штука, вот.
Применять её надо так.

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

Оригинальная статься недоступна, как метод полностью работает ещё досконально не понял, потому вопрос вот в чем: в таблице размер "окна" коэффициентов ограничен 12. А больше принципиально нельзя или просто выписывают ходовые начальные везде?
Дело в том, что данные очень хреновые будут, хочется добиться максимального качества.

Так я могу пытаться аппроксимировать полиномом ещё более высокого порядка (т.е. ограничить себя только размеров значащих точек данных) или есть причины этого не делать?

1

Оригинальная статья доступна по линку http://www.ee.oulu.fi/research... lPaper.pdf

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

0

Хехе, спасибо большое!

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

Хотя оно того стоило, результаты получаются как в Origin, пробовал библиотеку SDL - она так не умеет, там тоже лентяи ограничились шириной 25.
Если что - у меня теперь есть очень кривой, но относительно рабочий исходник на Delphi))

1

Genco, это круто) Поделись и Родина тебя не забудет)) Кстати, при ширине окна такого порядка уже нельзя отмахнуться от расчета краевых точек. Как выходили из этой ситуации?) Или при выходе на края спектра начинали уменьшать ширину окна, для уменьшения числа несглаженных точек?)

П.С. Жаль только, что я ничем особо интересным не могу поделится в ответ. Из методов сглаживания я могу только вейвлеты (
- Daubechies wavelets (1-32),
- Symlets (2-8),
- Coiflets (1-5),
- Biorthogonal wavelets (1-6)
- Reverse Biorthogonal wavelets (1-6)
это мое давнишнее развитие под D7 известной библиотеки WavUtils BaseGroup Labs для Delphi4
в оригинале были только Daubechies wavelets (1-10 порядка),
)
и мою программку для расчета коэффициентов сглаживания (линейного, квадратичного и кубического) и генерации исходного кода для Delphi. Изюминка - коэф-ты не только для центральной точки, но и для краевых. Ширина окна зависит только от точности расчета. Но, конечно, о 500 точках ширины окна речи и близко нет. (( линейное 3..21, квадратичное 5..21, кубическое 5..11. Теоретически, можно и большие ширины посчитать, но надо перейти на математику повышенной точности)

0

Да на здоровье, там кода всего ничего, только чур тапками за кривость больно не кидаться))
Считалка. Я ленивый читер, поэтому для обработки матрицы заюзал библиотеку ALGLIB. Как раз и математика там точная.
Каменты по делу - на инглише на случай порчи кодировки.

Сообщение от remax Кстати, при ширине окна такого порядка уже нельзя отмахнуться от расчета краевых точек. Как выходили из этой ситуации?) Или при выходе на края спектра начинали уменьшать ширину окна, для уменьшения числа несглаженных точек?)

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

Из человеческих решений проблемы пробовал два:
1) уменьшить непосредственно окно
2) Рассчитывая коэффициенты от -nl до nr не полагать, что abs(nl) = abs(nr) = window_size / 2 , вместо этого "смещать" аппроксимируемую точку, чтобы она была не посередине окна (nl < nr или nl > nr). При этом приходилось перерассчитывать коэффициенты для каждой точки.

В первом случае, возможно, что-то сделал не так, но данные я не просто сглаживал, а дважды дифференцировал, потому по краям из-за маленького окна оказывался адский шум, увеличение степени аппроксимирующего полинома не помогает с этим особо, ~3 достаточно и так.
Во втором - шума не было такого, но получалась какая-то ерунда, которая только мешалась.

Потому с краями как нормально поступить - вопрос всё ещё открытый, если есть идеи - буду рад выслушать))

-----

Ого, вейвлеты штука хорошая, они тоже не только сглаживать умеют, если я помню правильно.
А зачем могла понадобиться кодогенерация (хотя это и круто) на Delphi? оО

1

Сообщение от Genco А зачем могла понадобиться кодогенерация (хотя это и круто) на Delphi? оО

Просто от лени)
Согласись, что лень писать в программе что-то типа :
Это, например, всего только для одной из краевых точек для квадратичного сглаживания по 15... И только для этого метода необходимо еще 14 таких формул (по 7 слева и справа и 1 центральная = всего 15). И чем больше ширина окна, то тем больше формул и они длиннее)) Да и аккуратно надо все коэф-ты записывать, ничего не перепутав) Между прочим, я ошибки в таких формулах находил все 20 лет, сколько использую методы сглаживания))) что-то из-за ошибок в литературе, а что-то и по своей вине) Пока не сделал генератор, не был уверен на 100% в правильности)

Можно бы, конечно, сделать универсальную процедуру, а в массивах держать коэф-ты для всех точек и всех случаев. Только, любые универсальные методы хуже по быстродействию, ИМХО. Да и исторически сложилось уже так, что каждый метод расписан отдельно. И при добавлении следующего не хочется переделывать уже готовую идеологию)

Добавлено через 7 минут

Сообщение от Genco Ого, вейвлеты штука хорошая, они тоже не только сглаживать умеют, если я помню правильно.

Да, в вейвлетах большой потенциал. Например, анализ результатов разложения дает больше, чем результаты дифференцирования. (Это я все в ключе своих задач...) Только для сглаживания достаточно декомпозиция, затем неполная композиция) Ну, как в Фурье - разложили, а затем свернули не все) А для более умного применения все руки не доходят. Хотя и есть большая потребность...))

Добавлено через 10 минут
http://remaxsoft.ru/load/urm_w... a/5-1-0-32

0

Сообщение от remax Согласись, что лень писать в программе что-то типа :

Ааа, это)
Ну да, уже сталкивался с такой проблемой, но в моем случае получилось обойтись генератором коэффициентов. Ох, 20 лет это впечатляюще, респект))

А с моей колокольни вейвлеты порадовали тем, что в отличие от Фурье-анализа, там ещё и информация о времени добавляется.

За ссылку спасибо, такие хорошие штуки, да ещё и сразу на Delphi. Сколько б его не ругали и не хоронили, превосходный подручный инструмент, имхо.

0

Сообщение от Genco Я ленивый читер, поэтому для обработки матрицы заюзал библиотеку ALGLIB. Как раз и математика там точная. Каменты по делу - на инглише на случай порчи кодировки.

Я не совсем правильно выразился насчет точной математики)) При вычислении коэф-тов сглаживания весь прикол в том, что используется целочисленная арифметика. Т.е., точность вообще абсолютная))) Но! При увеличении ширины окна, с некого критичного значения этой величины для промежуточных расчетов начинает не хватать разрядности целочисленных типов. Даже 8-байтного int64... Есть методики для работы с целыми числами большой разрядности, но это требует существенной переделки программы. И пока не будет особой необходимости, нет мотивации этим заниматься))

Добавлено через 4 минуты

Сообщение от Genco Ааа, это) Ну да, уже сталкивался с такой проблемой, но в моем случае получилось обойтись генератором коэффициентов. Ох, 20 лет это впечатляюще, респект)) А с моей колокольни вейвлеты порадовали тем, что в отличие от Фурье-анализа, там ещё и информация о времени добавляется. За ссылку спасибо, такие хорошие штуки, да ещё и сразу на Delphi. Сколько б его не ругали и не хоронили, превосходный подручный инструмент, имхо.

Согласен на все 100%) Для большинства прикладных задач необходимо и достаточно использовать именно его) Оптимальный компромисс достаточной мощи возможностей и относительной простотой и логичностью))

0

Чуть не забыл) Обещанная программа расчета коэффициентов и генерации программного кода для "обычных методов" сглаживания "скользящим средним") http://remaxsoft.ru/load/smooth_v_1_0/3-1-0-33

1

О, не сразу заметил. Спасибо! Такая штука тож пригодится)

0

Вот, немного улучшил) http://remaxsoft.ru/load/smooth_v_1_2/3-1-0-35

Ограничения:
Максимальная ширина окна (N) для корректного вычисления коэффициентов сглаживания:
Линейное - 601
Квадратичное сглаживание - 163
Кубическое сглаживание - 39

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

Добавлено через 6 минут
Одна проблема - пока только для обычного "скользящего среднего". А к Савицкому-Голаю все никак не подступлюсь....

0