Without an already a deployed Python package this is going to be very difficult to get into the hands of Julia users via the Python route. I’m also not feeling very inspired to wade through the Python packaging process to figure out how to get this to work. Perhaps the conda-forge folks would be able to assist you with this.
Fair enough - my python package is still experimental. I think I should be able to get the python packaging done myself, but this may take some time. I’m busy with other stuff right now. If I get the python package together so that you can pip-install it I’ll let you know.
I’m also working on my Windows machine at the moment, so this is going to be difficult install an Ubuntu dependency.
The part of vigra that’s needed for vspline is just a bunch of headers, vigra is available for all common platforms. I did assume you were working on a linux machine, hence the proposed package. If you’re looking for other ways to install vigra, look at the vigra website.
*** I included the web site here, but julialang org informs me that I must not link to that host, so you’ll have to use a search engine to find the code. sorry for the inconvenience. *********
which also has a download section. You’ll only need the headers, not the library or the python interface (the latter is done with BOOST and I don’t use it)
Alternatively I might redistribute the vigra headers I use via my repo (as I already do with my own vspline headers), but before doing so I’ll ask the author to confirm that this is compatible with his license. This would reduce external dependencies.
If you opt to use Vc, this would require downloading that as well - it’s a dependency for the Vc variants of the shared library. You can find it here:
You’ll need the 1.4 branch of that repo. Using Vc requires linking a small static library (libVc.a) which is generated by the repo’s build mechanism. If you just want to go ahead and get something working fast, you can leave the use of Vc until later, it’s only effect is a welcome, but not dramatic, speedup of the code.
I would much rather target the shared library produced by this makefile:
We could probably get the dependencies packaged up via binarybuilder.org
I think this is a viable option, but it would reduce the scope to the pre-selected set of instantiations, namely 1-3D, 1-3channels, 32 and 64 bit floats. These should cover 95% of the use cases, though, and would already be a very useful amount of functionality. What would be lost in this approach is the exciting aspect of having further instantiations provided at run-time via cppyy.
If you opt to omit Vc for the time being, you’d only build the targets in the makefile with the ‘novc’ infix, and vigra would be the only dependency - plus pthreads for the multithreaded version, which may need additional installation steps on windows. I recommend you use clang++ to compile my code, but I’d be interested to see how msvc or the intel compiler performs. So far, I’ve only tested this build on linux with clang++ and g++.
The declarations and definitions for the given scope (which can easily be changed by modifying a few constants in the relevant headers set_*.h) result in fully-specialized template instantiations, which should be wrappable. The relevant starting point is vspline_binary.h
For the declarations, and the corresponding .cc file for the definitions. From there, it’s a cascade of repeating includes with different macro parameters, culminating in declare.h and use_apply.h, which have the macros for the actual declarations/definitions. If you follow the include hierarchy, you can see how the final outcome is a set of fully specialized template instantiations. This structured process should make it reasonably straightforward to add annotations if they should be needed by the wrapping code, but it would be nice if we could avoid intrusion into the C++ source.
Thanks for your continued interest! Getting the fixed-scope code wrapped should not be too hard, and I’m curious to see what your colleague might add to the discussion!