Closed bogovicj closed 3 years ago
Note: don't merge this quite yet, I'm going to add methodology to lazily compute the coefficients block-wise on demand.
Note: don't merge this quite yet, I'm going to add methodology to lazily compute the coefficients block-wise on demand.
You can mark the PR as a draft while you work on it. Then it cannot be merged yet. It's on the right side in the Reviewers tab
@axtimwalde
From the hotknife repo, I moved org.janelia.saalfeldlab.hotknife.util.Lazy
to net.imglib2.lazy.Lazy
, removing some of the Ops- related methods
TODO - make all added packages children of net.imglib2.algorithm
This pull request has been mentioned on Image.sc Forum. There might be relevant details there:
@axtimwalde @tpietzsch
This pull request adds two kinds of BSpline interpolation.
1) On the fly interpolation
The first is most similar to current interpolation methods:
This computes the interpolation kernel on-the-fly at every
get
. The kernel size is defined byradius
.clipping=true
sets the interpolator to behave like the ClampingNLinearInterpolator2) Precomputed coefficients
The second method precomputes BSpline coefficients and is substantially faster if
get
is called many times, but at the cost of memory - it allocates aRandomAccessibleInterval<T>
the same size as the image to be interpolated.T
defaults toDoubleType
. Use it like this:here the factory constructor computes the coefficients - which is why it needs to be passed. Unfortunately, this means that the
img
argument toViews.interpolate
is meaningless. For example,both result in the same thing. We stuck with this to keep the api consistent. No one should be doing the bottom thing anyway.
Generating the coefficients
BSplineDecomposition
andBSplineCoefficientsInterpolator
give more control for those who need it. For example