|
| | fir_filter (const fir_filter_specs &specs) |
| |
| int | get_support_width () const |
| | calling code may have to set up buffers with additional space around the actual data to allow filtering code to 'run up' to the data, shedding margin effects in the process. We stay on the safe side and return the width of the whole kernel, which is always sufficient to provide safe runup. More...
|
| |
| void | solve (const in_buffer_type &input, out_buffer_type &output) |
| | public 'solve' routine. This is for calls 'from outside', like when this object is used by itself, not as a base class of class convolve below. an extrapolator for the boundary condition code 'bc' (see fir_filter_specs) is made, then the call is delegated to the protected routine below which accepts an extrapolator on top of input and output. More...
|
| |
| | fir_filter_specs (vspline::bc_code _bc, int _ksize, int _headroom, const xlf_type *_kernel) |
| |
template<typename in_type, typename out_type = in_type, typename _math_type = out_type>
struct vspline::fir_filter< in_type, out_type, _math_type >
class fir_filter provides the 'solve' routine which convolves a 1D signal with selectable extrapolation. Here, the convolution kernel is applied to the incoming signal and the result is written to the specified output location. Note that this operation can be done in-place, but input and output may also be different. While most of the time this routine will be invoked by class convolve (below), it is also directly used by the specialized code for 1D filtering. Note how we conveniently inherit from the specs class. This also enables us to use an instance of fir_filter or class convolve as specs argument to create further filters with the same arguments.
Definition at line 132 of file convolve.h.
template<typename in_type , typename out_type = in_type, typename _math_type = out_type>
calling code may have to set up buffers with additional space around the actual data to allow filtering code to 'run up' to the data, shedding margin effects in the process. We stay on the safe side and return the width of the whole kernel, which is always sufficient to provide safe runup.
Definition at line 187 of file convolve.h.
template<typename in_type , typename out_type = in_type, typename _math_type = out_type>
public 'solve' routine. This is for calls 'from outside', like when this object is used by itself, not as a base class of class convolve below. an extrapolator for the boundary condition code 'bc' (see fir_filter_specs) is made, then the call is delegated to the protected routine below which accepts an extrapolator on top of input and output.
Definition at line 200 of file convolve.h.
template<typename in_type , typename out_type = in_type, typename _math_type = out_type>
protected solve routine taking an extrapolator on top of input and output. This way, the derived class (class convolve) can maintain an extrapolator fixed to it's buffer and reuse it for subsequent calls to this routine. we use the following strategy:
- keep a small circular buffer as large as the kernel
- have two kernels concatenated in another buffer
- by pointing into the concatenated kernels, we can always have ksize kernel values in sequence so that this sequence is correct for the values in the circular buffer. this strategy avoids conditionals as best as possible and should be easy to optimize. the actual code is a bit more complex to account for the fact that at the beginning and end of the data, a few extrapolated values are used. The central loop can directly read from input without using the extrapolator, which is most efficient.
Definition at line 227 of file convolve.h.
Public Member Functions inherited from vspline::fir_filter_specs