|
| enum | { channels = ExpandElementResult < value_type >::size
} |
| | number of channels in value_type More...
|
| |
| typedef _value_type | value_type |
| |
| typedef ExpandElementResult< value_type >::type | ele_type |
| | elementary type of value_type, like float or double More...
|
| |
| typedef bspline_base< _dimension > | base_type |
| |
| typedef vigra::MultiArray< dimension, value_type > | array_type |
| | if the coefficients are owned, an array of this type holds the data: More...
|
| |
| typedef vigra::MultiArrayView< dimension, value_type > | view_type |
| | data are read and written to vigra MultiArrayViews: More...
|
| |
| typedef bspline< value_type, dimension > | spline_type |
| | the type of 'this' bspline and of a 'channel view' More...
|
| |
| typedef bspline< ele_type, dimension > | channel_view_type |
| |
| typedef vigra::TinyVector< std::ptrdiff_t, dimension > | shape_type |
| | type of a multidimensional index type More...
|
| |
| typedef vigra::TinyVector< bc_code, dimension > | bcv_type |
| | nD type for one boundary condition per axis More...
|
| |
| enum | { dimension = _dimension
} |
| | 'suck in' the template argument More...
|
| |
| typedef vigra::TinyVector< std::ptrdiff_t, dimension > | shape_type |
| | type of a multidimensional index type More...
|
| |
| typedef vigra::TinyVector< bc_code, dimension > | bcv_type |
| | nD type for one boundary condition per axis More...
|
| |
| typedef vigra::TinyVector< xlf_type, dimension > | limit_type |
| | nD type for one limit condition per axis More...
|
| |
|
| | bspline (shape_type _core_shape, int _spline_degree=3, bcv_type _bcv=bcv_type(MIRROR), xlf_type _tolerance=-1.0, int headroom=0, view_type _space=view_type()) |
| | construct a bspline object with appropriate storage space to contain and process an array of knot point data with shape _core_shape. Depending on the the other parameters passed, more space than _core_shape may be allocated. Once the bspline object is ready, usually it is filled with the knot point data and then the prefiltering needs to be done. This sequence assures that the knot point data are present in memory only once, the prefiltering is done in-place. So the user can create the bspline, fill in data (like, from a file), prefilter, and then evaluate. More...
|
| |
| template<typename = std::enable_if < _dimension == 1 >> |
| | bspline (long _core_shape, int _spline_degree=3, bc_code _bc=MIRROR, xlf_type _tolerance=-1.0, int headroom=0, view_type _space=view_type()) |
| | overloaded constructor for 1D splines. This is useful because if we don't provide it, the caller would have to pass TinyVector < T , 1 > instead of T for the shape and the boundary condition. More...
|
| |
| channel_view_type | get_channel_view (const int &channel) |
| | get a bspline object for a single channel of the data. This is lightweight and requires the viewed data to remain present as long as the channel view is used. the channel view inherits all metrics from it's parent, only the MultiArrayViews to the data are different. More...
|
| |
| void | brace (int axis=-1) |
| | if the spline coefficients are already known, they obviously don't need to be prefiltered. But in order to be used by vspline's evaluation code, they need to be 'braced' - the 'core' coefficients have to be surrounded by more coeffcients covering the support the evaluator needs to operate without bounds checking inside the spline's defined range. brace() performs this operation. brace() assumes the bspline object has been set up with the desired initial parameters, so that the boundary conditions and metrics are already known and storage is available. brace() can be called for a specific axis, or for the whole container by passing -1. User code will only need to call 'brace' explicitly if the coefficients were modified 'from the outside' - when 'prefilter' is called, 'brace' is called automatically. More...
|
| |
| template<class math_ele_type = typename vigra::NumericTraits < ele_type > :: RealPromote, size_t vsize = vspline::vector_traits<math_ele_type>::size> |
| void | prefilter (vspline::xlf_type boost=vspline::xlf_type(1), int njobs=vspline::default_njobs) |
| | prefilter converts the knot point data in the 'core' area into b-spline coefficients. Bracing/framing will be applied. Even if the degree of the spline is zero or one, prefilter() can be called because it also performs the bracing. the arithmetic of the prefilter is performed in 'math_ele_type', which defaults to the vigra RealPromoted elementary type of the spline's value_type. This default ensures that integral knot point data are handled appropriately and prefiltering them will only suffer from quantization errors, which may be acceptable if the dynamic range is sufficiently large. 'boost' is an additional factor which will be used to amplify the incoming signal. This is intended for cases where the range of the signal has to be widened to fill the dynamic range of the signal's data type (specifically if it is an integral type). User code has to deal with the effects of boosting the signal, the bspline object holds no record of the 'boost' being applied. When evaluating a spline with boosted coefficients, user code will have to provide code to attenuate the resulting signal back into the original range; for an easy way of doing so, see vspline::amplify_type, which is a type derived from vspline::unary_functor providing multiplication with a factor. There is an example of it's application in the context of an integer-valued spline in int_spline.cc. More...
|
| |
| template<typename T , typename math_ele_type = typename vigra::NumericTraits < typename vigra::PromoteTraits < ele_type , ET<T> > :: Promote > :: RealPromote, size_t vsize = vspline::vector_traits<math_ele_type>::size> |
| void | prefilter (const vigra::MultiArrayView< dimension, T > &data, vspline::xlf_type boost=vspline::xlf_type(1), int njobs=vspline::default_njobs) |
| | If data are passed in, they have to have precisely the shape we have set up in core (_core_shape passed into the constructor). These data will then be used in place of any data present in the bspline object to calculate the coefficients. They won't be looked at after prefilter() terminates, so it's safe to pass in a MultiArrayView which is destroyed after the call to prefilter() returns. Any data residing in the bspline object's memory will be overwritten. here, the default math_ele_type ensures that math_ele_type is appropriate for both T and ele_type. More...
|
| |
| bool | shiftable (int d) const |
| | 'shift' will change the interpretation of the data in a bspline object. d is taken as a difference to add to the current spline degree. Coefficients remain the same, but creating an evaluator from the shifted spline will make the evaluator produce data as if the coefficients were those of a spline of the changed order. Shifting with positive d will efectively blur the interpolated signal, shifting with negative d will sharpen it. For shifting to work, the spline has to have enough 'headroom', meaning that spline_degree + d, the new spline degree, has to be greater or equal to 0 and smaller than the largest supported spline degree (lower fourties) - and, additionally, there has to be a wide-enough brace to allow evaluation with the wider kernel of the higher-degree spline's reconstruction filter. So if a spline is set up with degree 0 and shifted to degree 5, it has to be constructed with an additional headroom of 3 (see the constructor). More...
|
| |
| bool | shift (int d) |
| | shift() actually changes the interpretation of the data. The data will be taken to be coefficients of a spline with degree spline_degree + d, and the original degree is lost. This operation is only performed if it is technically safe (see shiftable()). If the shift was performed successfully, this function returns true, false otherwise. Note that, rather than 'shifting' the b-spline object, it's also possible to use a 'shifted' evaluator to produce the same result. See class evaluator's constructor. More...
|
| |
| xlf_type | lower_limit (const int &axis) const |
| |
| limit_type | lower_limit () const |
| |
| xlf_type | upper_limit (const int &axis) const |
| |
| limit_type | upper_limit () const |
| |
| xlf_type | lower_limit (const int &axis) const |
| |
| limit_type | lower_limit () const |
| |
| xlf_type | upper_limit (const int &axis) const |
| |
| limit_type | upper_limit () const |
| |
| | bspline_base (shape_type _core_shape, int _spline_degree, bcv_type _bcv, xlf_type _tolerance, int headroom) |
| | The constructor sets up all metrics of the spline from the basic properties given for the spline. Here, no defaults are offered, because this class is meant as a base class for splines only, and the expectation is that no objects of this class will be created. More...
|
| |
|
| static shape_type | get_container_shape (int spline_degree, bcv_type bcv, shape_type core_shape, int headroom) |
| | convenience method to caculate the shape of a container array needed to hold the coefficients of a spline with the given properties. The arguments are the same as those passed to the bspline object's constructor, but this method is static, so it can be called on the spline's type and does not need an object. I'm including this to make it easier for code which creates the container array externally before constructing the bspline object, rather than relying on class bspline to allocate it's own storage. More...
|
| |
| template<typename = std::enable_if < _dimension == 1 >> |
| static long | get_container_shape (int spline_degree, vspline::bc_code bc, long core_shape, int headroom) |
| | variant for 1D splines. This variant accepts the shape as a plain long, rather than requiring a TinyVector of one long. More...
|
| |
| static shape_type | get_left_brace_size (int spline_degree, bcv_type bcv) |
| | get_left_brace_size and get_right_brace_size calculate the size of the brace vspline puts around the 'core' coefficients to allow evaluation inside the defined range (and even slightly beyond) without bounds checking. These routines are static to allow user code to establish vspline's bracing requirements without creating a bspline object. user code might use this information to generate coefficient arrays suitable for use with vspline evaluation code, sidestepping use of a bspline object. More...
|
| |
| static shape_type | get_right_brace_size (int spline_degree, bcv_type bcv) |
| |
| static xlf_type | lower_limit (const bc_code &bc) |
| | lower_limit returns the lower bound of the spline's defined range. This is usually 0.0, but with REFLECT boundary condition it's -0.5, the lower point of reflection. The lowest coordinate at which the spline can be accessed may be lower: even splines have wider support, and splines with extra headroom add even more room to manoevre. More...
|
| |
| static xlf_type | upper_limit (const std::size_t &extent, const bc_code &bc) |
| | upper_limit returns the upper bound of the spline's defined range. This is normally M - 1 if the shape for this axis is M. Splines with REFLECT boundary condition use M - 0.5, the upper point of reflection, and periodic splines use M. The highest coordinate at which the spline may be accessed safely may be higher. More...
|
| |
| static xlf_type | lower_limit (const bc_code &bc) |
| | lower_limit returns the lower bound of the spline's defined range. This is usually 0.0, but with REFLECT boundary condition it's -0.5, the lower point of reflection. The lowest coordinate at which the spline can be accessed may be lower: even splines have wider support, and splines with extra headroom add even more room to manoevre. More...
|
| |
| static xlf_type | upper_limit (const std::size_t &extent, const bc_code &bc) |
| | upper_limit returns the upper bound of the spline's defined range. This is normally M - 1 if the shape for this axis is M. Splines with REFLECT boundary condition use M - 0.5, the upper point of reflection, and periodic splines use M. The highest coordinate at which the spline may be accessed safely may be higher. More...
|
| |
| static shape_type | get_left_brace_size (int spline_degree, bcv_type bcv) |
| | get_left_brace_size and get_right_brace_size calculate the size of the brace vspline puts around the 'core' coefficients to allow evaluation inside the defined range (and even slightly beyond) without bounds checking. These routines are static to allow user code to establish vspline's bracing requirements without creating a bspline object. user code might use this information to generate coefficient arrays suitable for use with vspline evaluation code, sidestepping use of a bspline object. More...
|
| |
| static shape_type | get_right_brace_size (int spline_degree, bcv_type bcv) |
| |
| static shape_type | get_container_shape (int spline_degree, bcv_type bcv, shape_type core_shape, int headroom) |
| | convenience method to caculate the shape of a container array needed to hold the coefficients of a spline with the given properties. The arguments are the same as those passed to the bspline object's constructor, but this method is static, so it can be called on the spline's type and does not need an object. I'm including this to make it easier for code which creates the container array externally before constructing the bspline object, rather than relying on class bspline to allocate it's own storage. More...
|
| |
| template<typename = std::enable_if < _dimension == 1 >> |
| static long | get_container_shape (int spline_degree, vspline::bc_code bc, long core_shape, int headroom) |
| | variant for 1D splines. This variant accepts the shape as a plain long, rather than requiring a TinyVector of one long. More...
|
| |
template<class _value_type, unsigned int _dimension>
struct vspline::bspline< _value_type, _dimension >
class bspline now builds on class bspline_base, adding coefficient storage, while bspline_base provides metadata handling. This separation makes it easier to generate classes which use the same metadata scheme. One concrete example is a class to type-erase a spline (not yet part of the library) which abstracts a spline, hiding the type of it's coefficients. Such a class can inherit from bspline_base and initialize the base class in the c'tor from a given bspline object, resulting in a uniform interface to the metadata. class bspline takes an additional template argument: the value type. This is the type of the coefficients stored in the spline, and it will typically be a single fundamental type or a small aggregate - like a vigra::TinyVector. vspline uses vigra's ExpandElementResult mechanism to inquire for a value type's elementary type and size, which makes it easy to adapt to new value types because the mechanism is traits-based.
Definition at line 497 of file bspline.h.
template<class _value_type , unsigned int _dimension>
construct a bspline object with appropriate storage space to contain and process an array of knot point data with shape _core_shape. Depending on the the other parameters passed, more space than _core_shape may be allocated. Once the bspline object is ready, usually it is filled with the knot point data and then the prefiltering needs to be done. This sequence assures that the knot point data are present in memory only once, the prefiltering is done in-place. So the user can create the bspline, fill in data (like, from a file), prefilter, and then evaluate.
alternatively, if the knot point data are already manifest elsewhere, they can be passed to prefilter(). With this mode of operation, they are 'pulled in' during prefiltering.
It's possible to pass in a view to an array providing space for the coefficients, or even the coefficients themselves. This is done via the parameter _space. This has to be an array of the same or larger shape than the container array would end up having given all the other parameters. This view is then 'adopted' and subsequent processing will operate on it's data.
The additional parameter 'headroom' is used to make the 'frame' even wider. This is needed if the spline is to be 'shifted' up (evaluated as if it had been prefiltered with a higher-degree prefilter) - see shift(). The headroom goes on top of the brace.
While bspline objects allow very specific parametrization, most use cases won't use parameters beyond the first few. The only mandatory parameter is, obviously, the shape of the knot point data, the original data which the spline is built over. This shape 'returns' as the bspline object's 'core' shape. If this is the only parameter passed to the constructor, the resulting bspline object will be a cubic b-spline with mirror boundary conditions, allocating it's own storage for the coefficients.
Note that passing tolerance = 0.0 may increase prefiltering time significantly, especially when prefiltering 1D splines, which can't use multithreaded and vectorized code in this case. Really, tolerance 0 doesn't produce significantly better results than the default, which is a very low value already. The tolerance 0 code is there more for completeness' sake, as it actually produces the result of the prefilter using the formula to calculate the initial causal and anticausal coefficient precisely, whereas the small tolerance used by default is so small that it roughly mirrors the arithmetic precision which can be achieved with the given type, which leads to nearly the same initial coefficients. Oftentimes even the default is too conservative - a 'reasonable' value is in the order of magnitude of the noise in the signal you're processing. But using the default won't slow things down a great deal, since it only results in the initial coefficients being calculated a bit less quickly. With nD data, tolerance 0 is less of a problem because the operation will still be multithreaded and vectorized.
Definition at line 634 of file bspline.h.
template<class _value_type , unsigned int _dimension>
template<typename T , typename math_ele_type = typename vigra::NumericTraits < typename vigra::PromoteTraits < ele_type , ET<T> > :: Promote > :: RealPromote, size_t vsize = vspline::vector_traits<math_ele_type>::size>
If data are passed in, they have to have precisely the shape we have set up in core (_core_shape passed into the constructor). These data will then be used in place of any data present in the bspline object to calculate the coefficients. They won't be looked at after prefilter() terminates, so it's safe to pass in a MultiArrayView which is destroyed after the call to prefilter() returns. Any data residing in the bspline object's memory will be overwritten. here, the default math_ele_type ensures that math_ele_type is appropriate for both T and ele_type.
Definition at line 859 of file bspline.h.
template<class _value_type , unsigned int _dimension>
template<class math_ele_type = typename vigra::NumericTraits < ele_type > :: RealPromote, size_t vsize = vspline::vector_traits<math_ele_type>::size>
prefilter converts the knot point data in the 'core' area into b-spline coefficients. Bracing/framing will be applied. Even if the degree of the spline is zero or one, prefilter() can be called because it also performs the bracing. the arithmetic of the prefilter is performed in 'math_ele_type', which defaults to the vigra RealPromoted elementary type of the spline's value_type. This default ensures that integral knot point data are handled appropriately and prefiltering them will only suffer from quantization errors, which may be acceptable if the dynamic range is sufficiently large. 'boost' is an additional factor which will be used to amplify the incoming signal. This is intended for cases where the range of the signal has to be widened to fill the dynamic range of the signal's data type (specifically if it is an integral type). User code has to deal with the effects of boosting the signal, the bspline object holds no record of the 'boost' being applied. When evaluating a spline with boosted coefficients, user code will have to provide code to attenuate the resulting signal back into the original range; for an easy way of doing so, see vspline::amplify_type, which is a type derived from vspline::unary_functor providing multiplication with a factor. There is an example of it's application in the context of an integer-valued spline in int_spline.cc.
Definition at line 815 of file bspline.h.
template<class _value_type , unsigned int _dimension>
'shift' will change the interpretation of the data in a bspline object. d is taken as a difference to add to the current spline degree. Coefficients remain the same, but creating an evaluator from the shifted spline will make the evaluator produce data as if the coefficients were those of a spline of the changed order. Shifting with positive d will efectively blur the interpolated signal, shifting with negative d will sharpen it. For shifting to work, the spline has to have enough 'headroom', meaning that spline_degree + d, the new spline degree, has to be greater or equal to 0 and smaller than the largest supported spline degree (lower fourties) - and, additionally, there has to be a wide-enough brace to allow evaluation with the wider kernel of the higher-degree spline's reconstruction filter. So if a spline is set up with degree 0 and shifted to degree 5, it has to be constructed with an additional headroom of 3 (see the constructor).
shiftable() is called with a desired change of spline_degree. If it returns true, interpreting the data in the container array as coefficients of a spline with the changed degree is safe. If not, the frame size is not sufficient or the resulting degree is invalid and shiftable() returns false. Note how the decision is merely technical: if the new degree is okay and the frame is large enough, the shift will be considered permissible.
Definition at line 926 of file bspline.h.
Public Types inherited from vspline::bspline_base< _dimension >