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

[Lee Kamentsky]

Thanks Tobias,
I ended up not using the KD tree for my composite ROI, but I wrote a 
hyperrectangle search class, 
net.imglib2.algorithm.kdtree.VolumetricSearch, anyway. I'm looking at 
net.imglib2.collection.KDTree and the searches in 
net.imglib2.neighborsearch and I can see those are better places for it 
now. I'll see if I can find some time to reimplement it there.

But, the one in algorithms works - it's pretty cool to have a database 
of N-dimensional intervals that you can search in log time.

--Lee

On 6/21/2011 1:21 PM, Tobias Pietzsch wrote:
> 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
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel