LabVIEW
Simple peak detection without threshold
Peak detection is a complex topic, but there's a simple solution if you simply need to automate finding peaks and valleys. If you simply define a peak as lying between valleys, you can use peakdet.vi, a port of a popular MATLAB script.
The LabVIEW code is available on my github, and attached here with a demo in LV2012.
Feedback is welcome.
While it seems to work, there are quite a few things I would change (and I haven't even looked at the FOR loop code!)
- Why do all the calculations execute even if an error occurs?
- Place the loop code in the false case and handle errors is the true case
- No, local variables don't simplify the code if done right and a sequence structure just clutters the diagram
- Reading delta from a local variable inside the loop eliminates many compiler optimizations, because the compiler must assume that it can change at any time.
- One error popup is sufficient, even if two different errors occur.
- etc.
Here's how it could look like. Arguably less clutter:
Yes, it is a good method, and often much faster and more flexible than the native peak finding routine in LabVIEW which you have to run twice if you want both peaks and valleys.
I believe I've posted my LabVIEW code on this a few years ago and even credited the idea to the original author Eli Bilauer ( LINK: http://billauer.co.il/peakdet.html )
I'll be curious to see how much faster Altenbach's code is than mine! 😉
Craig
@littlesphaeroid wrote:
Peak detection is a complex topic, but there's a simple solution if you simply need to automate finding peaks and valleys. If you simply define a peak as lying between valleys, you can use peakdet.vi, a port of a popular MATLAB script.
The LabVIEW code is available on my github, and attached here with a demo in LV2012.
Feedback is welcome.
Thanks Russell. I remember using this script with Matlab in the past.
One question - The algorithm depends on a delta between the valleys and peaks, why do you define this as "without threshold"? Isn't that delta the threshold?
@mcduff wrote:
One question - The algorithm depends on a delta between the valleys and peaks, why do you define this as "without threshold"? Isn't that delta the threshold?
Its a "relative" threshold (applied to the first derivative of the signal, not the signal itself) and the peak detection depends on two factors: (1) The relative difference between two adjacent points AND next point lower than second. I have the nagging feeling that this could be implemented with 10% of the current code. 😄
Quote from the text code comment:
% A point is considered a maximum peak if it has the maximal
% value, and was preceded (to the left) by a value lower by
% DELTA
Personally, this feels more like a "spike detector", because e.g. a beautifully smooth and wide gaussian peak would not be detected as such.
@littlesphaeroid wrote:
@altenbach wrote:
Personally, this feels more like a "spike detector", because e.g. a beautifully smooth and wide gaussian peak would not be detected as such.
a) A useless semantic distinction, and b) incorrect. On the latter point, there is no practical difference between a "broad" and some other gaussian, and peakdet is by design agnostic to noise ("smoothness"). But importantly, LabVIEW isn't a "feels" language. A simple test shows a Gaussian of any width is detected as long as it exceeds the delta value (as shown in the demo provided, which contains a trace with multiple gaussians)..
As demonstration, here are your examples with 5% Gaussian noise added: (and no, even tuning delta by an order of magnitude in either direction does not change the outcome).
Since delta depends on a first derivative and not on peak amplitude it is difficult to guess a good value without trying. A broad gaussian has nearly zero slope around the peak and any noise will overshadow the delta.
@littlesphaeroid wrote:
In my use case the data acquisition time is ~5 orders longer than the analysis. Running a 100kS data set through takes 2-5ms on my laptop. Improving its performance would not improve my application in any meaningful way, though I can see several routes to doing so. Have at big guy.
I was not talking about "run performance", just by the simple fact that if an algorithm can be explained in one sentence, it should not need a page full of complicated code. I am sure it could be done with 10%, making it 10x faster to write, easier to debug and there would be many fewer places for bugs to hide.
It should also be mentioned that [x] (if provided) must be sorted.
@altenbach wrote:Since delta depends on a first derivative and not on peak amplitude it is difficult to guess a good value without trying. A broad gaussian has nearly zero slope around the peak and any noise will overshadow the delta.
I have been using the WA Multiscale Peak Detection VI in the Advanced Signal Processing Toolkit for peak finding. It works well provided -
- Noisy data needs to be smoothed first, e.g., with a Savitzky-Golay Filter.
- The VI allows the user to detrend the data and remove the baseline if needed.
- The "width" needs to be well specified. The width is the number of samples of the peaks or valleys.
- You would need to run twice to get both peaks and valleys.
The peak fit contribution posed here is nice, small, easily accessible, but may not fit every situation. Below is the example from the Wavelet algorithm. When the signal is detrended, baseline removed works well, when not so well.
Baseline/Trend Removed
Baseline/Trend Not Removed
@altenbach wrote: some bad examples.
Showed provided examples not working after adding noise (to already noisy signals), used the provided default deltas, and claimed that changing the deltas did not affect the result.
I'd hoped it would be obvious that providing deltas larger than the noise and smaller than the peaks would produce the desired results:
