[ImageJ-devel] Local Neighborhood stuff

[Jean-Yves Tinevez]

Hi all

>> 
>> 
>> I cc'ed the imagej-devel list, because this should be of wider interest.
>> The gist of the mails quoted below is that we (Christian Dietz,
>> Jean-Yves Tinevez) are trying to unify the LocalNeighborhood (-Cursors)
>> that have been popping up in different places in ImgLib2.
>> Currently, most of the relevant source can be found in package
>> net.imglib2.algorithm.region.localneighborhood in algorithms-gpl.
>> Maybe Jean-Yves and Christian could provide some more information on the
>> individual neighborhoods that are implemented.
> 
> BufferedRectangularNeighborhood is a very simple ring-buffer implementation, to reduce the number of pixel-accesses (yes there is a speed-up).
> Additionaly I wrapped the HyperSphere stuff of Stephan Preibisch (HyperSphereNeighborhood).
> 
I think there is no need for that: there is already a HyperSphere class which has the role of the neighborhood. We need to convince Stephan to tweak it to fit into the hierarchy. 
>> 
>> 1.) Factory vs. CopyOn()
>> A factory could be constructed with parameters, for instance the
>> CellContainerFactory is constructed with cell dimensions. So a
>> HypersphereNeighborhood could be constructed with the radius for
>> example. However, I don't see much harm in adding the copyOn() method.
>> Having only updateSource() would be too little, as we might want to
>> change the type T of the Neighborhood in copyOn() and only keep the
>> structure.In general, I don't like the updateSource() very much. For
>> instance,what happens if the new source has a different number of
>> dimensions?
> I agree. As long as one can simulate the updateSource() behaviour (maybe with copyOn) everything is fine.
> But as you mentoined, how would we handle sources with more dimensions in copyOn? For instance copyOn on a RectangularNeighborhood (with 3,5,7 spans) is called with a
> 4-d source. What would be the span in this dimension?

I suggest by contract: 0. We would copy the span array to the new copy, and take the smallest array size as a limit. So that has soon as the numDimensions() are not equal, 0s are fed to the span. It is the role of the concrete implementation to ensure it makes sense. E.g.: copying a sphere to a 2D image should make it a disc. 

> 
>> 2.) Neighborhood interface
>> In addition to Positionable and IterableInterval, it could extend Localizable to get the position of the center.
> 
> Yap. Perfect.
> 
setSpan(long[] span);
span(long[] span);
copyOn(RandomAccessible<T> target)

I would like also to have a mother interface for the cursor, that would allow methods like

relativeDistance(int dim); // from the neighborhood center
relativeSquareDistance();
etc...


>> 
>> 3.) IN extends RandomAccessibleInterval<T> parameter in AbstractNeighborhood, etc
>> I think all the Neighborhoods should be constructed on
>> RandomAccessible<T> instead of RandomAccessibleInterval<T>.
>> If interval extension is required then this should be done outside of
>> the Neighborhood. If we do this, then the IN parameter is no longer
>> required, right? The Neighborhood is just constructed with any
>> RandomAccessible<T>.
> 
> Agree.
> 
Tobias also suggest to make a double type to be more generic than just ExtendedRI etc… Could you do it? I am not strong enough with the generics to make it right.


>> 4.) move to imglib2 core
>> Eventually, the neighborhood should be moved to the core, maybe with the
>> exception of rather special-case stuff like DiscNeighborhood.
>> Or is ops a better place? What do you think?
> 
> From my point of view it should be in the core, as these are basic data-structures.
> 
When the first 3 concrete implementations are done ok? 

Also i plan on removing DiscNeighborhood and SphereNeighborhood from imglib2: they are too specific and clumsy and do not fit what we are designing here. They are related to the ability to position a neighborhood using calibrated, real coordinates, as is x = 6.5 µm, etc.. taking advantage of the calibration in IngPlus<T> 

The neighborhood hierarchy we are designing deal with pixel coordinates only and this is right. 

Cheers
jy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120726/bb9e5ca3/attachment.html>