I've written some peak picking functions that work in N dimensions for a module for looking at NMR data in python, http://code.google.com/p/nmrglue/. I'd be glad to polish up the code if people think it would be a useful addition to scipy.ndimage or scipy.interpolate? The methods are not based on any formal algorithms I know of, just some fast and relatively simple methods that I found seem to work decently.
The methods are contained in the peakpick.py and segmentation.py files in the analysis directory (specifically see the find_all_connected, find_all_ downward and find_all_thres): http://code.google.com/p/nmrglue/source/browse/trunk/nmrglue/analysis/peakpick.py http://code.google.com/p/nmrglue/source/browse/trunk/nmrglue/analysis/segmentation.py Let me know if there is an interest in including these in scipy or numpy. -Jonathan Helmus Jacob Silterra wrote: > >What is your application? > > The most common case is looking at Fourier transforms and identifying > spectral peaks. I've also analyzed images looking at 1D slices > (usually very regular data) and looked for peaks there. > > That stackoverflow page had a nice link to a comparison of different > algorithms here: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2631518/. > That paper is focused on mass-spectrometry data, but the approach > would generalize to any 1D data set. Unless somebody feels otherwise, > I'll close this pull request and start working on an implementation of > peak finding via continuous wavelet transform (the best and most > computationally intensive approach of those described above). > > -Jacob > > ------------------------------ > > Message: 4 > Date: Tue, 13 Sep 2011 22:34:01 +0200 > From: Ralf Gommers <[email protected] > <mailto:[email protected]>> > Subject: Re: [Numpy-discussion] Functions for finding the relative > extrema of numeric data > To: Discussion of Numerical Python <[email protected] > <mailto:[email protected]>> > Message-ID: > > <cabl7cqhxcx0lkfenmw6-4zsbdiegxz04zbsrny4bxyvxvl7...@mail.gmail.com > > <mailto:cabl7cqhxcx0lkfenmw6-4zsbdiegxz04zbsrny4bxyvxvl7...@mail.gmail.com>> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Jacob, > > On Fri, Sep 9, 2011 at 11:57 PM, Jacob Silterra <[email protected] > <mailto:[email protected]>> wrote: > > > Hello all, > > > > I'd like to see functions for calculating the relative extrema > in a set of > > data included in numpy. I use that functionality frequently, and > always seem > > to be writing my own version. It seems like this functionality > would be > > useful to the community at large, as it's a fairly common operation. > > > > What is your application? > > > > > For numeric data (which is presumably noisy), the definition of > a relative > > extrema isn't completely obvious. The implementation I am > proposing finds a > > point in an ndarray along an axis which is larger (or smaller) > than it's > > `order` nearest neighbors (`order` being an optional parameter, > default 1). > > This is likely to find more points than may be desired, which I > believe is > > preferable to the alternative. The output is formatted the same as > > numpy.where. > > > > Code available here: https://github.com/numpy/numpy/pull/154 > > > > I'm not sure whether this belongs in numpy or scipy, that > question is > > somewhat debatable. More sophisticated peak-finding functions (in N > > dimensions, as opposed to 1) may also be useful to the > community, and those > > would definitely belong in scipy. > > > > I have the feeling this belongs in scipy. Although if it's just > these two > functions I'm not sure where exactly to put them. Looking at the > functionality, this is quite a simple approach. For any data of > the type I'm > usually working with it will not be able to find the right local > extrema. > The same is true for your alternative definition below. > > A more powerful peak detection function would be a very good > addition to > scipy imho (perhaps in scipy.interpolate?). See also > > http://stackoverflow.com/questions/1713335/peak-finding-algorithm-for-python-scipy > > Cheers, > Ralf > > > > An alternative implementation would be to require that function be > > continuously descending (or ascending) for `order` points, which > would > > enforce a minimum width on a peak. > > > > -Jacob Silterra > > > > _______________________________________________ > > NumPy-Discussion mailing list > > [email protected] <mailto:[email protected]> > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110913/8bb2e1a5/attachment-0001.html > > ------------------------------ > > Message: 5 > Date: Tue, 13 Sep 2011 15:44:03 -0500 > From: Benjamin Root <[email protected] <mailto:[email protected]>> > Subject: Re: [Numpy-discussion] Functions for finding the relative > extrema of numeric data > To: Discussion of Numerical Python <[email protected] > <mailto:[email protected]>> > Message-ID: > > <cannq6fk973uwz7+uxwc55p3ircuam36cubfc_nupxqdi0r7...@mail.gmail.com > > <mailto:cannq6fk973uwz7%2buxwc55p3ircuam36cubfc_nupxqdi0r7%[email protected]>> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue, Sep 13, 2011 at 3:34 PM, Ralf Gommers > <[email protected] > <mailto:[email protected]>>wrote: > > > Hi Jacob, > > > > On Fri, Sep 9, 2011 at 11:57 PM, Jacob Silterra > <[email protected] <mailto:[email protected]>> wrote: > > > >> Hello all, > >> > >> I'd like to see functions for calculating the relative extrema > in a set of > >> data included in numpy. I use that functionality frequently, > and always seem > >> to be writing my own version. It seems like this functionality > would be > >> useful to the community at large, as it's a fairly common > operation. > >> > > > > What is your application? > > > >> > >> For numeric data (which is presumably noisy), the definition of > a relative > >> extrema isn't completely obvious. The implementation I am > proposing finds a > >> point in an ndarray along an axis which is larger (or smaller) > than it's > >> `order` nearest neighbors (`order` being an optional parameter, > default 1). > >> This is likely to find more points than may be desired, which > I believe is > >> preferable to the alternative. The output is formatted the same as > >> numpy.where. > >> > >> Code available here: https://github.com/numpy/numpy/pull/154 > >> > >> I'm not sure whether this belongs in numpy or scipy, that > question is > >> somewhat debatable. More sophisticated peak-finding functions (in N > >> dimensions, as opposed to 1) may also be useful to the > community, and those > >> would definitely belong in scipy. > >> > > > > I have the feeling this belongs in scipy. Although if it's just > these two > > functions I'm not sure where exactly to put them. Looking at the > > functionality, this is quite a simple approach. For any data of > the type I'm > > usually working with it will not be able to find the right local > extrema. > > The same is true for your alternative definition below. > > > > A more powerful peak detection function would be a very good > addition to > > scipy imho (perhaps in scipy.interpolate?). See also > > > > http://stackoverflow.com/questions/1713335/peak-finding-algorithm-for-python-scipy > > > > Cheers, > > Ralf > > > > > Actually, such an algorithm would be great to partner with the > watershed > clustering implementation in ndimage. > > Ben Root > > ------------------------------------------------------------------------ > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
