Closed bogovicj closed 5 months ago
Another point: existing code does a nearest neighbor search but this PR uses a radius search.
InverseDistanceWeightingInterpolatorFactory
implements InterpolatorFactory< T, KNearestNeighborSearch<T>>
emphasis on the KNearestNeighborSearch
.
In this PR:
RadialKDTreeInterpolatorFactory
implements InterpolatorFactory<T, KDTree<T>>
but internally uses a RadiusNeighborSearchOnKDTree
we could make RadialKDTreeInterpolatorFactory
implement InterpolatorFactory<T, RadiusNeighborSearchOnKDTree<T>>
, if that's preferable.
Hi, what is the math that defines what happens when the points overlap? I think there are some similarities with what I have written in STIM ... would be great to catch up on that (https://github.com/PreibischLab/STIM/blob/master/src/main/java/render/Render.java) ...
@StephanPreibisch ,
Yea, the code in this PR is similar to what you have in STIM, in the same ways that it's similar to what is here in imglib2. It's also different from what's in STIM in the ways its different from the imglib2 code. Some of your code there could do well in imglib2 core in my view. Summary of the differences
NumericType
s (current impls use RealType
sThe math is:
$$ \sum_{p \in P} f (r^2) v(p) $$
where $P$ is all the points within some radius. and $v(p)$ is whatever value the point $p$ has (needed to build the KDTree). and $f$ is a developer-provided function of the squared radius.
This PR adds an interpolator for KDTrees that takes a custom function of the (squared) radius to produce a
RealRandomAccessible
. This is similar to but more general than the existingInverseDistanceWeightingInterpolatorFactory
which uses a particular class of functions for the radius. Another difference -InverseDistanceWeightingInterpolatorFactory
usesRealType
, the classes provided by this PR can use anyNumericType
.The demo below produces this output: