[vspline] 53/72: minor changes to the example programs, eval.h
Kay F. Jahnke
kfj-guest at moszumanska.debian.org
Sun Jul 2 09:02:42 UTC 2017
This is an automated email from the git hooks/post-receive script.
kfj-guest pushed a commit to branch master
in repository vspline.
commit 50418f86ec8227fb80de11b373cf7283d7edf343
Author: Kay F. Jahnke <kfjahnke at gmail.com>
Date: Wed May 3 12:03:32 2017 +0200
minor changes to the example programs, eval.h
---
coordinate.h | 103 ------------------------------------------------
eval.h | 58 +++++++--------------------
example/pano_extract.cc | 4 ++
mapping.h | 2 +-
remap.h | 20 ++++------
unary_functor.h | 2 +-
6 files changed, 28 insertions(+), 161 deletions(-)
diff --git a/coordinate.h b/coordinate.h
deleted file mode 100644
index a39d3cb..0000000
--- a/coordinate.h
+++ /dev/null
@@ -1,103 +0,0 @@
-/************************************************************************/
-/* */
-/* vspline - a set of generic tools for creation and evaluation */
-/* of uniform b-splines */
-/* */
-/* Copyright 2015 - 2017 by Kay F. Jahnke */
-/* */
-/* The git repository for this software is at */
-/* */
-/* https://bitbucket.org/kfj/vspline */
-/* */
-/* Please direct questions, bug reports, and contributions to */
-/* */
-/* kfjahnke+vspline at gmail.com */
-/* */
-/* Permission is hereby granted, free of charge, to any person */
-/* obtaining a copy of this software and associated documentation */
-/* files (the "Software"), to deal in the Software without */
-/* restriction, including without limitation the rights to use, */
-/* copy, modify, merge, publish, distribute, sublicense, and/or */
-/* sell copies of the Software, and to permit persons to whom the */
-/* Software is furnished to do so, subject to the following */
-/* conditions: */
-/* */
-/* The above copyright notice and this permission notice shall be */
-/* included in all copies or substantial portions of the */
-/* Software. */
-/* */
-/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND */
-/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES */
-/* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND */
-/* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT */
-/* HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, */
-/* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING */
-/* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR */
-/* OTHER DEALINGS IN THE SOFTWARE. */
-/* */
-/************************************************************************/
-
-/*! \file coordinate.h
-
- \brief a traits class for coordinates
-
- Throughout the evaluation part of vspline, we deal with coordinates.
- To handle these types their components consistently, we define a
- traits class 'coordinate_traits'.
-
-*/
-
-// TODO: maybe this is overspecification... I was using presplit coordinates
-// earlier, so it made sense to have this traits class, but I threw out that
-// part of the code, so now it seems a bit verbose to go this way.
-
-#ifndef VSPLINE_COORDINATE_H
-#define VSPLINE_COORDINATE_H
-
-#include <vigra/tinyvector.hxx>
-
-namespace vspline {
-
-/// first we fix 'unsplit' nD coordinate types as vigra TinyVectors
-
-template < int dimension ,
- typename ic_type >
-using nd_ic_type = vigra::TinyVector < ic_type , dimension > ;
-
-template < int dimension ,
- typename rc_type >
-using nd_rc_type = vigra::TinyVector < rc_type , dimension > ;
-
-/// now for the traits class. we want it to provide the following types:
-/// ic_type, rc_type, nd_ic_type and nd_rc_type. We also want an enum 'dimension'
-/// giving the dimension of the coordinate.
-
-template < class coordinate_type >
-struct coordinate_traits
-{
- typedef coordinate_type rc_type ;
- typedef int ic_type ;
- enum { dimension = 1 } ;
-
- typedef vigra::TinyVector < rc_type , dimension > nd_rc_type ;
- typedef vigra::TinyVector < ic_type , dimension > nd_ic_type ;
-} ;
-
-/// here we have a partial specialization of class coordinate_traits for coordinates
-/// coming as vigra TinyVectors, which is used throughout for nD coordinates. Here we
-/// pick the TinyVector's value_type as our rc_type
-
-template < typename _rc_type , int _dimension >
-struct coordinate_traits < vigra::TinyVector < _rc_type , _dimension > >
-{
- enum { dimension = _dimension } ;
- typedef _rc_type rc_type ;
- typedef int ic_type ;
-
- typedef vigra::TinyVector < rc_type , dimension > nd_rc_type ;
- typedef vigra::TinyVector < ic_type , dimension > nd_ic_type ;
-} ;
-
-} ; // end of namespace vspline
-
-#endif // VSPLINE_COORDINATE_H
diff --git a/eval.h b/eval.h
index 4ea819d..cdd9d06 100644
--- a/eval.h
+++ b/eval.h
@@ -106,7 +106,7 @@ using namespace vigra ;
// TODO describe the use of the 'weight matrix' rather than technical details
/// The routine 'calculate_weight_matrix' originates from vigra. I took the original
-/// routine BSplineBase<ORDER, T>::calculateWeightMatrix() from vigra and changed it
+/// routine BSplineBase<spline_order, T>::calculateWeightMatrix() from vigra and changed it
/// in several ways:
///
/// - the spline degree is now a runtime parameter, not a template argument
@@ -172,9 +172,9 @@ MultiArray < 2 , target_type > calculate_weight_matrix ( int degree , int deriva
/// along the different axes, but this introduced too much extra complexity for my taste and
/// took me too far away from simply providing efficient code for b-splines, so I abandoned
/// the attempts. Therefore the weight functors for a specific spline all have to have a common
-/// ORDER and generate ORDER weights. The only way to force lesser order weight functors into
+/// spline_order and generate spline_order weights. The only way to force lesser order weight functors into
/// this scheme if it has to be done is to set some of the weights to zero. Weight functors
-/// of higher ORDER than the spline can't be accomodated, if that should be necessary, the ORDER
+/// of higher spline_order than the spline can't be accomodated, if that should be necessary, the spline_order
/// of the entire spline has to be raised.
///
/// Note the use of 'delta' in the functions below. this is due to the fact that these functors
@@ -532,15 +532,14 @@ private:
const nd_mapping_type mmap ; ///< mapping of real coordinates to spline coordinates
bspline_weight_functor_type wfd0 ; ///< default weight functor: underived bspline
const int spline_degree ;
- const int ORDER ;
- const int workspace_size ;
+ const int spline_order ;
const int window_size ;
public:
const int & get_order() const
{
- return ORDER ;
+ return spline_order ;
}
const int & get_degree() const
@@ -566,13 +565,11 @@ public:
derivative_spec_type _derivative = derivative_spec_type ( 0 ) )
: coefficients ( _coefficients ) ,
spline_degree ( _spline_degree ) ,
- ORDER ( _spline_degree + 1 ) ,
+ spline_order ( _spline_degree + 1 ) ,
component_view ( _coefficients.expandElements ( 0 ) ) ,
expanded_stride ( channels * _coefficients.stride() ) ,
wfd0 ( _spline_degree , 0 ) ,
- mmap ( _mmap ) , // I enforce the passing in of a mapping, even though it
- // may not be used at all. TODO: can I do better?
- workspace_size ( ( _spline_degree + 1 ) * dimension ) ,
+ mmap ( _mmap ) ,
window_size ( std::pow ( _spline_degree + 1 , int(dimension) ) )
{
// initalize the weight functors. In this constructor, we use only bspline weight
@@ -610,7 +607,7 @@ public:
// and calculate the pointer difference for every element reached. We use the
// same loop to code the corresponding offsets to elementary values (ele_type)
- auto sample = coefficients.subarray ( shape_type() , shape_type(ORDER) ) ;
+ auto sample = coefficients.subarray ( shape_type() , shape_type(spline_order) ) ;
auto base = sample.data() ;
auto target = offsets.begin() ;
auto component_target = component_offsets.begin() ;
@@ -646,7 +643,7 @@ public:
evaluator ( const bspline < value_type , dimension > & bspl ,
derivative_spec_type _derivative ,
- mcv_type mcv
+ mcv_type mcv = mcv_type ( vspline::MAP_REJECT )
)
: evaluator ( bspl.coeffs ,
nd_mapping_type ( bspl.bcv , mcv , bspl.spline_degree , bspl.core_shape ) ,
@@ -720,7 +717,7 @@ public:
{
auto ci = c.cbegin() ;
for ( int axis = 0 ; axis < dimension ; ++ci , ++axis )
- (*(fweight[axis])) ( weight.data() + axis * ORDER , *ci ) ;
+ (*(fweight[axis])) ( weight.data() + axis * spline_order , *ci ) ;
}
/// obtain weight for a single axis
@@ -773,7 +770,7 @@ public:
/// at level 0 the recursion ends, now we finally apply the weights for axis 0
/// to the window of coefficients. Note how ofs is passed in per reference. This looks
/// wrong, but it's necessary: When, in the course of the recursion, the level 0
- /// routine is called again, it needs to access the next bunch of ORDER coefficients.
+ /// routine is called again, it needs to access the next bunch of spline_order coefficients.
/// Just incrementing the reference saves us incrementing higher up.
template < class dtype >
@@ -918,7 +915,7 @@ public:
/// representing the origin of the coefficient window to process, second the fractional parts
/// of the coordinate which are needed to calculate the weights to apply to the coefficient
/// window. Note that the weights aren't as many values as the window has coefficients, but
- /// only ORDER weights per dimension; the 'final' weights would be the outer product of the
+ /// only spline_order weights per dimension; the 'final' weights would be the outer product of the
/// sets of weights for each dimension, which we don't explicitly use here. Also note that
/// we limit the code here to have the same number of weights for each axis.
/// Here we have the code for the specializations affected by the template argument
@@ -954,15 +951,7 @@ public:
{
// general case. this works for degree 0 and 1 as well, but is less efficient
- // To calculate the weights we want efficient storage, being very much inner-loop here,
- // but at the same time we want adequate packaging for the weights as well. So we obtain
- // the memory by creating an adequately-sized C++ array right here (cheap, no new needed)
- // and package it in a MultiArrayView, which is also cheap.
-
- ele_type weight_data [ workspace_size ] ; // get space for the weights
- MultiArrayView < 2 , ele_type > // package them in a MultiArrayView
- weight ( Shape2 ( ORDER , dimension ) , // with dimension sets of ORDER weights
- weight_data ) ; // using the space claimed above
+ MultiArray < 2 , ele_type > weight ( Shape2 ( spline_order , dimension ) ) ;
// now we call obtain_weights, which will fill in 'weight' with weights for the
// given set of fractional coordinate parts in 'tune'
@@ -1416,26 +1405,7 @@ public:
}
else
{
- // like in the unvectorized code, the 2D MultiArrayView to the weights is created
- // as a view to data on the stack (weight_data) which is lightweight and fast.
- // It is of course tempting to have this array handy as a member of class evaluator,
- // but this would produce mutable state and make class evaluator thread-unsafe
- // and no longer a 'pure' functor in a functional programming sense, so we use
- // this bit of artistry here.
-
- // ... but clang++ does not accept this (variable sized array of non-POD type)
- // When the second variant is used, the code runs here compiled with clang++,
- // but not when compiled with gcc (probably due to an alignment problem),
- // so I have this TODO ugly ifdef :( and TODO make sure the clang-specific code
- // is safe regarding alignment
-
-#ifndef __clang__
- ele_v weight_data [ workspace_size ] ;
- MultiArrayView < 2 , ele_v > weight ( Shape2 ( ORDER , dimension ) , weight_data ) ;
-#else
- ele_type weight_data [ workspace_size * vsize ] ;
- MultiArrayView < 2 , ele_v > weight ( Shape2 ( ORDER , dimension ) , (ele_v*)weight_data ) ;
-#endif
+ MultiArray < 2 , ele_v > weight ( Shape2 ( spline_order , dimension ) ) ;
// obtain_weights is the same code as for unvectorized operation, the arguments
// suffice to pick the right template arguments
diff --git a/example/pano_extract.cc b/example/pano_extract.cc
index 80db098..860ac52 100644
--- a/example/pano_extract.cc
+++ b/example/pano_extract.cc
@@ -92,7 +92,11 @@ typedef vigra::MultiArray<2, pixel_type> array_type ;
typedef vigra::MultiArrayView<2, pixel_type> view_type ;
typedef vigra::TinyVector < float , 2 > coordinate_type ;
+#ifdef USE_VC
#define VSIZE (vspline::vector_traits<float>::size)
+#else
+#define VSIZE 1
+#endif
/// concatenation of roll, pitch and yaw into a single quaternion
/// we use a right-handed coordinate system: the positive x axis points towards us,
diff --git a/mapping.h b/mapping.h
index 07ae82b..fb0ad3f 100644
--- a/mapping.h
+++ b/mapping.h
@@ -111,7 +111,7 @@
#include <vigra/multi_iterator.hxx>
#include "common.h"
-#include "coordinate.h"
+// #include "coordinate.h"
namespace vspline {
diff --git a/remap.h b/remap.h
index 3570645..20f96b4 100644
--- a/remap.h
+++ b/remap.h
@@ -563,20 +563,16 @@ void apply ( const unary_functor_type & ev ,
template < typename coordinate_type , // type of coordinates in the warp array
typename value_type , // type of values to produce
int dim_out > // number of dimensions of output array
-int remap ( const MultiArrayView < coordinate_traits < coordinate_type > :: dimension ,
- value_type > & input ,
- const MultiArrayView < dim_out ,
- coordinate_type > & warp ,
- MultiArrayView < dim_out ,
- value_type > & output ,
- bcv_type < coordinate_traits < coordinate_type > :: dimension > bcv
- = bcv_type < coordinate_traits < coordinate_type > :: dimension >
- ( MIRROR ) ,
+int remap ( const MultiArrayView
+ < vigra::ExpandElementResult < coordinate_type > :: size ,
+ value_type > & input ,
+ const MultiArrayView < dim_out , coordinate_type > & warp ,
+ MultiArrayView < dim_out , value_type > & output ,
+ bcv_type < vigra::ExpandElementResult < coordinate_type > :: size > bcv
+ = bcv_type < vigra::ExpandElementResult < coordinate_type > :: size > ( MIRROR ) ,
int degree = 3 )
{
- const int dim_in = coordinate_traits < coordinate_type > :: dimension ;
- typedef typename coordinate_traits < coordinate_type > :: rc_type rc_type ;
- typedef typename coordinate_traits < coordinate_type > :: ic_type ic_type ;
+ const int dim_in = vigra::ExpandElementResult < coordinate_type > :: size ;
// check shape compatibility
diff --git a/unary_functor.h b/unary_functor.h
index d324ec5..32633a4 100644
--- a/unary_functor.h
+++ b/unary_functor.h
@@ -47,7 +47,7 @@
#define VSPLINE_UNARY_FUNCTOR_H
#include <vspline/common.h>
-#include <vspline/coordinate.h>
+// #include <vspline/coordinate.h>
namespace vspline {
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/vspline.git
More information about the debian-science-commits
mailing list