[ImageJ-devel] Local Neighborhood stuff

[Tobias Pietzsch]

Hi,

 >>> 2.) Neighborhood interface
 > setSpan(long[] span);
 > span(long[] span);
 > copyOn(RandomAccessible<T> target)

I think, the "span" concept is too specialised for the interface.
The assumption is that the bounding box of the neighborhood structuring 
element is 2*span[d]+1 in every dimension. The anchor point is assumed 
to be the center of this neighborhood.

We should think of non-symmetric neighborhoods as well.
I suggest that instead of a long[] span, we use an Interval to specify 
the bounding box. The anchor point is always the (0,0,...,0) of the 
interval. The above span would translate to interval.min[d] = -span[d], 
interval.max[] = span[d].

What would setSpan() do? Does this change the size and shape of the 
structuring element?

 >
 > 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...

Ok. I wonder whether all Neighborhoods should be required to implement 
this. Maybe we could have a hierarchy of interfaces. Neighborhood just
supplies a Cursor. NeighborhoodExt extends Neighborhood supplies a 
Cursor that also implements interface for relativeDistance() etc.

Note, that it is easy to write a generic wrapper that takes a 
Neighborhood and turns it into NeighborhoodExt by wrapping the Cursors.
So if you just want to hack up a Neighborhood quickly you wouldn't need 
to bother with implementing relativeDistance() etc.

Of course, I do not suggest to name the thing "NeighborhoodExt"...
:-)

 >> 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?

Sounds good!

best regards,
Tobias


On 07/26/2012 09:30 AM, Jean-Yves Tinevez wrote:
> 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