[vspline] branch packaging created (now fd20652)

[Kay F. Jahnke]

This is an automated email from the git hooks/post-receive script.

kfj-guest pushed a change to branch packaging
in repository vspline.

        at  fd20652   created packaging branch, added folder 'debian' to it The package building scripts in debian/ are in order to build homebrew packages, but will need small modifications to be usable by debian

This branch includes the following new commits:

       new  c648364   Initial commit of README.rst
       new  ac366e4   Initial commit of vspline's source code and examples
       new  137845d   some changes to the documentation, rewrite of vectorized prefilter My initial implementation of the vectorized prefiltering routine was functional, but it was based on iterators which I wrote when I initially worked the solver with the arrays' data directly, which took some finessing and a proxy type. When my speed tests showed that buffering was the way to go and I made it the standard modus operandi, the code became overly complex for the task. So I decided to rewr [...]
       new  8692fea   broadened simdized type in prefilter, saved 1 thread two small changes with performance gains which surprised me. The first one is changing simdized_type in the vectorized prefiltering code from plain Vc::Vector<ele_type> to a SimdArray twice that size. The performance gain isn't much, but seems to be a few percent and every little helps. It's just one place in the code where the change is done and it trickles down, so it's easy to change back or try something else.  [...]
       new  bec223f   Factored out most of the prefiltering code to filter.h I noticed that the prefiltering code which was initially in prefilter.h was very close to a general routine performing the type of filter needed for b-spline prefiltering. So I factored it out into filter.h, which does not have any code specific to b-splines and implemented the b-spline-specific routines in prefilter.h as thin wrappers of the top-level function in filter.h. at the same time, I restructured the co [...]
       new  131eeac   Finished coding for the 1D specialization of the filter I feel I've now found a reasonable path treating 1D arrays, where large arrays will benefit very much and resource still aren't stretched too far. I also did some minor changes in the filter code, now passing the gain to the filter instead of the previous lambda_exponent, the new method is more flexible.
       new  12f8485   moved allocation of workspace to evaluator, moved vector type fixing to traits class with the vector type now fixed in a traits class, I managed to globally change the simdized type to a SimdArray with twice the Vc::Vector size, which resulted in ca. 15% overall eval performance gain. And I moved the allocation of the 'workspace' into class evaluator, which makes it more like the functor I have in mind when I rework the remap code.
       new  f616c7b   finally found a satisfactory way to make class evaluator thread safe and still fast.
       new  2594723   more work on evaluation, class warper introduced I did some more work on class evaluator, adding code to work with separate sources of integral and real components of split coordinates. This made it possible to use a new class 'warper' in remap.h, which contains two MultiArray(View)s, one to nD integral coordinates, one to nD real remainders. I wrote the corresponding remap function (for now requiring the arrays in the warper to be unstrided) and tested, seems like a [...]
       new  7528e65   using aggregate_traits throughout, work on pv.cc I'm trying to push some more fixed types out, so now I've worked on vigra::TinyVecors, replacing them with aggregate_traits<T,N>::type. I'd like to move to code where the aggregated types 'collapse' to simple type T if N==1, but I still have trouble getting my code to work with this definition. Anyway, factoring more of the type-fixing out is a good idea. I've also had good fun with pv. I tuned it some more and by now  [...]
       new  fecd7fc   new code for multithreading, currently in impulse_response.cc ... where it could be easily developed and tested. I was unhappy with 'divide_and_conquer' and wanted generalized code for multithreading over sections of manifolds. Staring out with several attempts (still in this commit) using tuples, I finally figured out that it would be best to introduce proper notions of 'range' and 'partitioning' and use them explicitly. I now have a multithreading routine which is  [...]
       new  a29afea   factored out multithreading code into multithread.h, using it in filter.h Now that I rewrote the multithreading code, I need to make some changes to the code using multithreading as well, since I introduced the passing of ranges together with the 'whole' arguments to the single-thread code and the signatures are slightly different. In this intermediate commit, the old code in common.h (splite_array_to_cunks, divide_and_conquer) is still present and used for evaluatio [...]
       new  8e7ee9d   multithread() from multithread.h now used for all multithreading I did the rewrite of the code for multithreading in remap.h and pv.cc. This made the 'divide_and_conquer' code in common.h obsolete. While using multithread() I found no way to pass references 'through' multithread(), so now I use pointers throughout to do the passage. Changing the single-threaded code turned out straightforward by simply adding the extra range parameter, changing all access to manifold [...]
       new  441efc5   small changes, documentation
       new  a98fa86   polishing, new bc code TAG, remap now takes evaluator, not bspline Initially I had plans to have a pure virtual base class interpolator, specifying an interface for interpolating code, and inherit this interface in class evaluator. For now I've abandoned this path. what I have changed, though, is the remap routines: they now take an evaluator object instead of a bspline. This is a step in the same direction; a bspline object is pretty much what I had in mind for an ' [...]
       new  3cde5ed   changed shifting code, smaller changes to pv I now save the initial boundary conditions used for prefiltering and revert to them during 'shifting' of the spline, because the shifting produced erroneous results with REFLECT bcs when the spline was later run with RTAG maping mode. pv now runs fine with all combinations of pan-mode and HQ splines and with full and partial sphericals - it takes a few extra command line arguments to fix the degrees for same, and has the a [...]
       new  90457ed   added interpolator.h interpolator.h has an interface definition for a class 'interpolator' with those methods defined pure virtual which are essential for remapping from unsplit coordinates. class evaluator fulfills this interface, but since the interface only requires a few methods to be present, it's quite easy to write alternative interpolators, as 'nearest_neighbour' in the same file, which provides a possibly minimally faster implementation of nearest-neighbour  [...]
       new  79e7258   polished mapping code now all the mappings resort to the raw mappings, reducing code redundancy. also some minor changes there, added more documentation.
       new  a74968a   stutter-free panning in pv I found ways to avoid dropped frames in pv. I took several measures: - the frames are now rendered in a separate thread with some rendering ahead-of-time   so that the overall rate is steadier - if there are still dropped frames, I decrease the apparent frame rate by   showing all frames twice thrice etc. - with showing them twice I'm still   at 30 fps, which looks smooth if it's not panning too fast So now I can run fine with linear interp [...]
       new  ec8aa61   polished pv some more I tweaked nn and bilinear interpolation and now I get most panos to run at 60fps and bilinear without stutter. Only when the panorama is very large or the fov is very large (or near zenith or nadir) I have to throttle.
       new  8221de1   mainly work on multithreading, pv I changed the multithreading code to use a thread pool. At the same time I introduced new joint processing code which makes the multithreading more fine-grained, so that the workload is more evenly distributed to the worker threads. The new code is partly in multithread.h, which has the joint task handling, and partly in thread_pool.cc, which has to be compiled separately and linked in. pv is using the new methods. The biggest change [...]
       new  68692ee   consolidated opertion with thread pool, now header-only.
       new  1e26342   added code for evaluation of mesh grids to remap.h
       new  7fd27c7   pv now uses image pyramid To further reduce stutter with large panoramas, I added code to use a pyramid of slightly smoothed, scaled down spline objects which are put to use depending on the scale of the display. I commit this status quo because it seems to be a nice milestone without any immediately obvious bugs.
       new  34c802d   nice working state of pv. license change of pv to GPL3 pv now has smooth zooming and panning at 60 fps for most cases.
       new  23550f6   removed gradient.cc
       new  fd9ed9e   nice working state of pv
       new  44dcbc9   commit before removing pv.cc
       new  92a1b56   license change of pano_extract to GPL3, proper CL argument handling
       new  4b0bc8d   polished multithreading code, (hopefully) fixing one bug
       new  f738e1a   added coordinate.h
       new  188fd41   worked on eval.h; now have specialized code for NN and linear interpolation inside class evaluator, which made my handcoded interpolators in pv obsolete. Also added a new mapping mode fo splines made with REFLECT bcs which don't actually need the reflection and can be evaluated RAW. The new mapping mode RRAW takes care of the brace which may be widened.
       new  af741ec   added specializations for splines of degree 0 and 1 to have specialized nearest-neighbour and linear interpolators in vspline, which makes it as fast as hand-coded code for the purpose. Also introduced 'evenness' for raw-mode remaps without using mmap.
       new  438354c   removed tf_remap I have done away with tf_remap in favour of only providing index_remap. index_remap can be used to the same effect, but burdens the implementation of a transformation object on the calling code. Yet wrapping an evaluator in an outer object which can do the necessary transformation isn't hard, and doing so is more efficient than using the slightly awkward vspline::transform object (though it's auto-broadcast method seemed like a good idea at the time. [...]
       new  8b78ec8   small changes
       new  a503691   minor changes
       new  e55930b   coded unary_functor.h as replacement for interpolator.h The type system and template args in interpolator.h still showed it's origin in eval.h, but what was encoded in interpolator.h is a broader concept of a unary functor, taking an n-dimensional input and producing an m-dimensional output, plus the vectorization and load/store methods. So I rewrote the code reflecting the workings of a unary functor and made the corresponding changes to other code. In some places I [...]
       new  5b1d08d   removed interpolator.h from the repository
       new  9262c14   small changes due to problems showing up with example code these are mainly type changes in filter.h and eval.h. also added a few more examples with simple tasks (slice.cc, complex.cc)
       new  f36607f   added two examples, gsm.cc and gsm2.cc, which calculate the gradient squared magnitude of an image, the first implementation using dirct evaluation of the gradients in a loop as a quick shot, the second implementation creating a dedicated gsm evaluator and producing the result by using vspline::index_remap
       new  7f335e9   some changes to the remapping code I had a bug (which did not manifest) in the handling of the recursive descent of warp_generator, which is fixed now, together with a bit of tweaking for speed. I now always recurse all the way to 1D, which resolves some type issues.
       new  9f272ab   mainly work on remap.h This was consolidation work and performance tuning, also streamlining of the code to make it more compact. Added more comments, as well.
       new  ba9cbac   mainly documentation work
       new  94e54cf   fixed bug for REFLECT BCs and small arrays went through examples to make sure all compile and work
       new  aaff60b   work on documentation, fixed use_vc bug while writing documentation (front page for doxygen docu) I noticed that calls to high-level routines with use_vc set to a specific value did not always produce correct results. This was due to the flag's value not being carried all the way through to where it should have been evaluated. this should be fixed now, and roundtrip behaves as expected.
       new  4075e7b   removed the use_vc flag in all it's guises. Now use of Vc is either switched on (by defining USE_VC) or off (default). compiles with USE_VC will alwways (try to) run the vector code. Switching off the use of the vector code in a comile with USE_VC defined is no longer an option.
       new  ea649cc   added script to compile all examples
       new  aaaedc2   documentation
       new  a02e20f   added map.h, with new implementation of teating out-of-bounds coordinates I was never really happy with the code in mapping.h with it's function pointers and the mixup between mapping and splitting of coordinates. So now I thought out a different way of doing the task. I want bspline objects to now have const bcv's and have the coordinate pretreatment via specialized types. map.h now has the basis for doing this: there is a collection of 'gate' types which are derive [...]
       new  4f6ceb3   committing changes in map.h before branching
       new  5002ac1   separated boundary conditions and mapping codes I was unhappy with both voundary conditions and mappings sharing the same enum and being conceptually linked. Now there is a separate set of mapping codes (in common.h) and the mapping code in mapping.h is based on them. When creating evaluators from bspline objects, the old automatism of picking a mapping which 'echoed' the spline's boundary conditions was removed, the default now is to use MAP_REJECT, which throws vsp [...]
       new  64234aa   wrote restore function using grid_eval, changes to roundtrip.cc
       new  50418f8   minor changes to the example programs, eval.h
       new  3e38f24   changed template argument signature of grid_eval
       new  290494e   polishing, mainly documantation
       new  bfdb9e4   small change to documentation
       new  42dc63b   added link to documantation
       new  128b6f6   polished documentation
       new  81ee242   getting the documentatation hyperlink right...
       new  244a232   clened up code in filter.h, documentation
       new  3af786c   minor change to comment
       new  b258fa4   added vspline::bspline::brace() This method simply applies the brace using either coefficients already present in the spline's core or 'pulling in' a coefficient array first. This way, externally generated coefficients can easily be used to set up a bspline object for evaluation with vspline's evaluation code.
       new  669e768   changed gather/scatter with extrusion code and it's use Given a simdized type ST, I noticed recently that, apart from using  ST::IndexType (which uses int) for gather/scatter operations, I can  use any type offering operator[] and holding the required number of  indexes. Initially I filed this under nice-to-have, but since the code  I'm working on produces indexes initially as ptrdiff_t  (which is long on my system), I experimentally coded passing  vigra::TinyVector< [...]
       new  0ce0fdd   activating code in filter.h to use IndexType for gathering if indexes fit
       new  392ee6b   change to vspline::bspline's parameter signature, polishing I moved the parameter _space to the end of bspline's constructor's argument list, since it should rarely be used. The other changes were to the comments, and also a change to class bspline's method container_size() which had a bug with SPHERICAL/REFLECT BCs. This caused problems with pano_extract in the examples, when the source image had an alpha channel, so pano_extract was changed as well.
       new  3c44400   minor change to comments only
       new  06a3663   more minor changes
       new  9a7c8cc   more minor changes
       new  57f11a5   threw out a diagnostic message, commit before branch
       new  58db62d   threw out BC code IGNORE, since it is really the same as ZEROPAD. Apparently, IGNORE mustn't be used in certain environments because it is occupied by something already. No problem, we don't need it anyway.
       new  48e31ca   removed use of a vla in prefilter.h
       new  6c6a977   modified multithread's partitioning behaviour multithread now takes a function pointer determine the partitioning function. In remap.h, partition_to_tiles is used by default. This routine has been modified to fall back to partition_to_stripes if the shape passed in isn't 2D or the partitioning to tiles doesn't yield the desired number of parts. This way, most use cases should be adequately covered, but specific needs for partitioning can also be addressed.
       new  fd20652   created packaging branch, added folder 'debian' to it The package building scripts in debian/ are in order to build homebrew packages, but will need small modifications to be usable by debian

The 73 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/vspline.git