[ImageJ-devel] Local Neighborhood stuff

[Tobias Pietzsch]

Hi,

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.

Some comments with respect to the previous mails

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?

2.) Neighborhood interface
In addition to Positionable and IterableInterval, it could extend 
Localizable to get the position of the center.

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

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?

best regards,
Tobias




On 07/24/2012 09:12 AM, Jean-Yves Tinevez wrote:
 >
 >
 > On Tue, Jul 24, 2012 at 8:53 AM, Christian Dietz
 > <christian.dietz at uni-konstanz.de
 > <mailto:christian.dietz at uni-konstanz.de>> wrote:
 >
 > Hi Tobi,
 >
 > thinking of parameters. Each neighborhood may have a different amount
 > of parameters like radius, spans etc...
 >
 >
 > Which leads us to the question: What do we want in the Neighborhood
 > interface? It has to be Positionable and IntervalIterable, but what
 > do we add to this?
 >
 > Initially I put a setSpan(long[] size); method, because I thought
 > that every neighborhood would have some size that could be set. The
 > span would then have the meaning of the bounding box radius. It doe
 > snot work if we want to put /e.g./ Brensenham lines there.
 >
 > What else?

On 07/23/2012 08:45 PM, Christian Dietz wrote:
 > Hi,
 >
 > yes I was also thinking about a factory, but again I ran into
 > problems. Imagine the following scenario:
 >
 > You've an operation which operates on a Neighborhood & Image, so you
 > give it a Neighborhood in the Constructor. Any Img<T> is passed in
 > the compute call of the. The operation can be applied on any Img<T>
 > (e.g. compute(A img, A res)), but if the op can't set the source of a
 > neighborhood the op can't be reused.
 >
 > Best regards,
 >
 > Christian
 >
 >
 >
 > -----Original Message----- From: Tobias Pietzsch
 > [mailto:pietzsch at mpi-cbg.de] Sent: Montag, 23. Juli 2012 17:27 To:
 > Christian Dietz Cc: 'Jean-Yves Tinevez' Subject: Re: Local
 > Neighborhood stuff
 >
 > Hi,
 >
 > In similar situations we often used a factory in imglib2. So, would a
 > NeighborhoodFactory instead of a copy/updateSource method work here?
 >
 > best regards, Tobias
 >
 > On 07/21/2012 09:03 PM, Christian Dietz wrote:
 >> Just one more remark (as I ran into problems ;))
 >>
 >> Just recognized that instead of the copy(IN source) something like
 >> updateSource(IN source) would be better. In addition a constructor
 >> of a AbstractNeighborhood(int numDims,… xy) should also be
 >> available (see knip_deployment for examples).
 >>
 >> What do you think?
 >>
 >> *From:*Jean-Yves Tinevez [mailto:jeanyves.tinevez at gmail.com]
 >> *Sent:* Samstag, 21. Juli 2012 20:32 *To:* Christian Dietz *Cc:*
 >> Tobias Pietzsch; Martin Horn *Subject:* Re: Local Neighborhood
 >> stuff
 >>
 >> Sorry mail was sent a bit early. I should not write with a baby on
 >> my lap.
 >>
 >> I just had a look again at the LocalNeighborhood stuff which came
 >> up the last days in algorithms-gpl.
 >>
 >> It looks pretty much as the things we did some weeks ago. Our
 >> solution was less sophisticated, that’s  why I converted the
 >> “delta” to the solution of Jean-Yves
 >> (BufferedRectangleNeighborhoodCursor and the Wrapper for the
 >> HyperSphere/Cursor of Stephan P.).
 >>
 >>
 >> Ok careful, the Sphere iterator is not a wrapper for the
 >> HyperSphere of Stephan: It gives you an actual ellipsoid (3
 >> different semi axes) and only iterate over the first 3 dimension by
 >> privileging the Z axis. Stephan Hypersphere is nD generic, and is
 >> an actual sphere in pixel coordinates.
 >>
 >> Several questions/suggestions came up, which I would like to
 >> discuss with you so that we maybe have one consolidated package to
 >> work on? ; )
 >>
 >> (i)Why in algorithms-gpl? Could also be put into the core of
 >> algorithms or even imglib2?
 >>
 >> Because I thought the code was clumsy compared to the elegance of
 >> Stephan's sphere, and I did not dare put it in the core.
 >>
 >> (ii)Could we parameterize AbstractNeighborhood<T, IN extends
 >> RandomAccessibleInterval<T>>? Especially in the case of the
 >> OutOfBoundsStrategy this could make sense (less casting).
 >>
 >> Oki.
 >>
 >> (iii)Could we add a method like copy(IN source) to
 >> AbstractNeighborhood? It’s nice if one could create instances of
 >> any AbstractNeighborhood from a given neighborhood.
 >>
 >> You mean create the same kind of neighborhood on a different
 >> source? Oki.
 >>
 >> (iv)Maybe we could add an Interface Neighborhood<T, IN extends
 >> RandomAccessibleInterbal<T>>?
 >>
 >>
 >> Tobias?
 >>
 >> We should also add the HyperSphere/Cursor of Stephan to this
 >> package.
 >>
 >> I made some changes and pushed them into knip_deployment
 >> algorithms-gpl etc!
 >>
 >>
 >> As soon as I am back to University I will also fix the formatting,
 >> sorry for that ;)
 >>
 >> Have a nice weekend,
 >>
 >>
 >> Thanks! cheers jy
 >>
 >

On 07/21/2012 07:01 PM, Christian Dietz wrote:
> Hi Tobi & Jean-Yves,
>
> I just had a look again at the LocalNeighborhood stuff which came up the
> last days in algorithms-gpl.
>
> It looks pretty much as the things we did some weeks ago. Our solution
> was less sophisticated, that’s  why I converted the “delta” to the
> solution of Jean-Yves (BufferedRectangleNeighborhoodCursor and the
> Wrapper for the HyperSphere/Cursor of Stephan P.).
>
> Several questions/suggestions came up, which I would like to discuss
> with you so that we maybe have one consolidated package to work on? ; )
>
> (i)Why in algorithms-gpl? Could also be put into the core of algorithms
> or even imglib2?
>
> (ii)Could we parameterize AbstractNeighborhood<T, IN extends
> RandomAccessibleInterval<T>>? Especially in the case of the
> OutOfBoundsStrategy this could make sense (less casting).
>
> (iii)Could we add a method like copy(IN source) to AbstractNeighborhood?
> It’s nice if one could create instances of any AbstractNeighborhood from
> a given neighborhood.
>
> (iv)Maybe we could add an Interface Neighborhood<T, IN extends
> RandomAccessibleInterbal<T>>?
>
> We should also add the HyperSphere/Cursor of Stephan to this package.
>
> I made some changes and pushed them into knip_deployment algorithms-gpl etc!
>
>
> As soon as I am back to University I will also fix the formatting, sorry
> for that ;)
>
> Have a nice weekend,
>
> Christian
>