[ImageJ-devel] net.imglib2.algorithm.kdtree and rectangles

[Tobias Pietzsch]

On 06/10/2011 03:33 PM, Lee Kamentsky wrote:
> Hi all, esp Dscho & Stephan P. I'm thinking of doing a composite region
> of interest which would be a collection any other kinds of region of
> interest. I'm thinking that the most efficient way to do this is to use
> a K-D tree to store references to the sub-ROIs: Wikipedia says that you
> can search for hyper-rectangles (the bounds of the ROIs) by storing the
> minimum and maximum extents as a 2N-d object in the hyperplane and then
> the search for rectangles containing a point becomes a range search in
> the 2N-d space for all points on one side of a hyperplane.
>
> So 2 questions:
>
> 1) Could I add a leaf that holds onto a real interval,
> "RealntervalLeaf<I extends RealInterval>", a search method that returns
> all points on one side of a hyperplane (T point, Node<T> node, bool []
> above = false to retrieve nodes less than point in the given dimension,
> true to retrieve nodes greater than point in the given dimension) and
> some wrapper class that purports to be a database of "I extends
> RealInterval" with a simple interface for retrieving all RealIntervals
> containing a point?


Hi Lee,

I'm a bit out of the loop right now, just getting back into imglib 
development. I don't know if this has been discussed in the Skype 
channel or something, but...

Did you consider using the new KDTree implementation in imglib2 core, 
instead of the net.imglib2.algorithm.kdtree?

The new KDTree does not require it's T to be a Leaf< T >
and there are implementations of the 
net.imglib2.neighborsearch.*NeighborSearch< T > interfaces.

It uses exact median-finding algorithm for constructing the tree
(instead of the approximate one in net.imglib2.algorithm.kdtree).

It is also faster, if I remember correctly.

best regards,
Tobias


>
> 2) imglib2-algorithms is really useful. There are going to be other
> cases where imglib2 or other components would like to use algorithms to
> construct things like NativeImg and RegionOfInterest. How do we manage
> this? It sure would be nice if imglib2 and imglib2-algorithms were
> interdependent. If we're not going to allow that, I'll probably
> implement the composite ROI in imglib2-algorithms and I'll wait until
> imglib2-algorithms to be completed before I use composite ROIs in ImageJ
> 2.0.
>
> I'm probably going to do the first for the fun of it, the legacy ROI
> code will need it, need a break from the GUI stuff and this will be
> refreshing. Tell me what you all think.
>
> --Lee
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel