Back to the main page.

Bug 1981 - consider implementing a cheby2 filter in ft_preproc_xxxfilter

Reported 2013-02-08 21:03:00 +0100
Modified 2015-01-12 09:24:44 +0100
Product: FieldTrip
Component: preproc
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 enhancement
Assigned to: Jan-Mathijs Schoffelen
Depends on: 2033
See also:

Jan-Mathijs Schoffelen - 2013-02-08 21:03:00 +0100

there seems to exist an octave version for the computation of the coefficients, so no signal processing toolbox is requested in that case. I am not too familiar with the specifics of the chebyshev filter characteristics myself. for the rest it would be pretty straightforward, and analogous to e.g. the butterworth filter

Jan-Mathijs Schoffelen - 2013-02-09 16:37:38 +0100

I looked into the filter design a bit more, and noticed that the Chebyshev type 2 filter actually has quite a variable response in the pass and stop bands, but is admittedly much steeper than the butterworth filter. One issue that warrants discussion in order for it to be really neatly implemented in FT and accessible from preproc, is that an extra parameter is needed. As such this can be dealt with generically as additional key-value pairs for the ft_preproc_xxxfilter functions, but once we go this track, we may reconsider using key-value pairs throughout.

Jan-Mathijs Schoffelen - 2013-02-10 09:09:30 +0100

now we're at it: there's also a firls implementation in the octave signal toolbox (from which we use a lot of overloaded code, to remove dependency on the signal processing toolbox). Consider to do a drop-in replacement for firls TO DO: -test the octave implementation versus the matlab implementation

Jan-Mathijs Schoffelen - 2013-02-11 11:25:00 +0100

octave's firls implementation seems to yield the same results as the signal processing toolbox one, up to numerical round off. -ONLY when the filter order is even it seems. -coefficients are returned as a column-vector, rather than column

Jan-Mathijs Schoffelen - 2014-09-10 14:52:39 +0200

OK, this has been considered but so far not implemented. I think with the recent external contribution of well-behaved filter functions, I don't want to push this any further. Therefore I will close this for now. Feel free to re-open if you have very good arguments.