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
_______________________________________________
ImageJ-devel mailing list
[email protected]
http://imagej.net/mailman/listinfo/imagej-devel
