confusing number of peaks in ThresholdPeakDetector

[Wolfgang]

Hello,

today I have tried the function ThresholdPeakDetector and was surprised by the following result: the array of peak indices returned contained four values (different from zero), while the return value for the number_of_peaks was only 3...

ThresholdPeakDetector ( y,points,threshold,8,peak_array,&number_of_peaks );
 

Should I assume now 4 peak values (number_of_peaks + 1), or discard one of the array values?  

Thank you

Wolfgang

[PeterAdelhardt]

Hi Wolfgang,

when you look into the definition of the "ThresholdPeakDetector" function you will find that you will receive the actual number of peaks in the parameter "numberOfPeakIndices". The size of the "peakIndices" Array is defined by you before running the Peak detection. CVI will only write the peaks it detected to that array. Therefore, all values of that array past the last real index are not touched by CVI. If there is a value (!=0), it's not a valid one!

Short answer: Check the parameter "numberOfPeakIndices" first, then you can look up that number of values in the peakIndices array from 0 to "numberOfPeakIndices"-1.

If you have further questions, don't hesitate to ask!

Best regards,

Peter

[Wolfgang]

Dear Peter,

thank you for your answer. What you are writing is exactly what I had expected according to the documentation. However, as mentioned, this is not what the function does.

First, I dynamically allocate memory for an integer array using calloc, according to the help, ( points / min_peak_width + 1 ); in the current case this is 11.

Second, I initialize all the array values with 0. (and check it in debug mode)

Third, I run the function and receive two return values: one, the array with the indices, second, the number of indices.

In my example the first 6 values of the array have changed from 0, and display e.g. 4405, 4581, 4594, 4647, 4662, 4838, that is, sorted. AND, 6 values, while the second return value tells me, that it there should only be 5 peaks...

Since all 6 maximum values look reasonable, I have no clue, which one should be wrong; in fact, I think that all values are correct and that the second return value is too small, by one.

Wolfgang

[PeterAdelhardt]

Hi Wolfgang,

could you provide me with some code, so I could reproduce the error? I just tried it with a simple example and random data. It always works as expected.

Thanks,

Peter

[PeterAdelhardt]

Hi Wolfgang,

when setting the width > 1 and allocating the result array dynamically I was able to reproduce the issue. I will try and get R&D involved to clarify this behavior. I will keep you posted. Thanks for pointing out this issue!

Peter

Message Edited by PaSB on 01-15-2009 03:05 PM

[Wolfgang]

Thanks for confirmation 🙂 This permits me to skip the 'demo' application...

Wolfgang

[PeterAdelhardt · Accepted solution]

Hi Wolfgang,

I filed an internal error report and will keep you posted on the issue. By playing around with the function I found out that

- the issue is only dependend on the peak width > 1

- the last value is always incorrect (at least from what I observed), so the first "numberOfPeakIndices" array values are correct. 

Best regards,

Peter

[Wolfgang]

Thank you, Peter,

for taking care of this problem and your further investigations. In my case, 'needles' with a width of only 1 make no sense, that's why I am using a lower limit such as 8 (or even much larger). So for the time until the next release I will simply ignore the last peak, and rely on the value of numberOfPeakIndices.

Have a nice weekend,

Wolfgang

[Wolfgang]

Hi Peter,

if NI is working on this function anyway, let me suggest some other change: Right now the function returns the first index value that belongs to a peak with a given threshold. In my opinion, it would make much more sense to return the center of the peak position fulfilling the threshold condition. Example: a peak spans from index 239 to index 269 - ThresholdPeakDetector returns index 239, it might be more useful to return index 254. 

Of course, for the current implemenation that only supports a peak width of 1 this makes no difference, but for the more general definition of a peak it does. That's why, for the time being, I am using my own function that returns both position and width of all the peaks with an amplitude in excess of a given threshold value.

Wolfgang

[PeterAdelhardt]

Hi Wolfgang,

thanks for the additional input. What you mention would, however, require another piece of information per peak.

Let's say the function returns the exact peak value. Now, if your peak width is even (e.g. 4) or large (e.g. 20) you will not know the exact boundaries of that peak shape (start, end) when you know the peak value. Both pieces of information (max value index, start index) are valuable. What I will propose (and so can you on this page) is a switch for selecting "peak start" OR the "peak max" index as a resulting parameter or maybe both. Just like your manual function you described. Thanks again for the input. 

Peter