
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi all</div><div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I cc'ed the imagej-devel list, because this should be of wider interest.<br></blockquote><blockquote type="cite">The gist of the mails quoted below is that we (Christian Dietz,<br></blockquote><blockquote type="cite">Jean-Yves Tinevez) are trying to unify the LocalNeighborhood (-Cursors)<br></blockquote><blockquote type="cite">that have been popping up in different places in ImgLib2.<br></blockquote><blockquote type="cite">Currently, most of the relevant source can be found in package<br></blockquote><blockquote type="cite">net.imglib2.algorithm.region.localneighborhood in algorithms-gpl.<br></blockquote><blockquote type="cite">Maybe Jean-Yves and Christian could provide some more information on the<br></blockquote><blockquote type="cite">individual neighborhoods that are implemented.<br></blockquote><br>BufferedRectangularNeighborhood is a very simple ring-buffer implementation, to reduce the number of pixel-accesses (yes there is a speed-up).<br>Additionaly I wrapped the HyperSphere stuff of Stephan Preibisch (HyperSphereNeighborhood).<br><br></div></blockquote><div>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. </div><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">1.) Factory vs. CopyOn()<br></blockquote><blockquote type="cite">A factory could be constructed with parameters, for instance the<br></blockquote><blockquote type="cite">CellContainerFactory is constructed with cell dimensions. So a<br></blockquote><blockquote type="cite">HypersphereNeighborhood could be constructed with the radius for<br></blockquote><blockquote type="cite">example. However, I don't see much harm in adding the copyOn() method.<br></blockquote><blockquote type="cite">Having only updateSource() would be too little, as we might want to<br></blockquote><blockquote type="cite">change the type T of the Neighborhood in copyOn() and only keep the<br></blockquote><blockquote type="cite">structure.In general, I don't like the updateSource() very much. For<br></blockquote><blockquote type="cite">instance,what happens if the new source has a different number of<br></blockquote><blockquote type="cite">dimensions?<br></blockquote>I agree. As long as one can simulate the updateSource() behaviour (maybe with copyOn) everything is fine.<br>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<br>4-d source. What would be the span in this dimension?<br></div></blockquote><div><br></div><div>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. <i>E.g.: </i>copying a sphere to a 2D image should make it a disc. </div><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite">2.) Neighborhood interface<br></blockquote><blockquote type="cite">In addition to Positionable and IterableInterval, it could extend Localizable to get the position of the center.<br></blockquote><br>Yap. Perfect.<br><br></div></blockquote><div>setSpan(long[] span);</div><div>span(long[] span);</div><div>copyOn(RandomAccessible<T> target)</div><div><br></div><div>I would like also to have a mother interface for the cursor, that would allow methods like</div><div><br></div><div>relativeDistance(int dim); // from the neighborhood center</div><div>relativeSquareDistance();</div><div>etc...</div><div><br></div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">3.) IN extends RandomAccessibleInterval<T> parameter in AbstractNeighborhood, etc<br></blockquote><blockquote type="cite">I think all the Neighborhoods should be constructed on<br></blockquote><blockquote type="cite">RandomAccessible<T> instead of RandomAccessibleInterval<T>.<br></blockquote><blockquote type="cite">If interval extension is required then this should be done outside of<br></blockquote><blockquote type="cite">the Neighborhood. If we do this, then the IN parameter is no longer<br></blockquote><blockquote type="cite">required, right? The Neighborhood is just constructed with any<br></blockquote><blockquote type="cite">RandomAccessible<T>.<br></blockquote><br>Agree.<br><br></div></blockquote><div>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.</div><div><br></div><br><blockquote type="cite"><div><blockquote type="cite">4.) move to imglib2 core<br></blockquote><blockquote type="cite">Eventually, the neighborhood should be moved to the core, maybe with the<br></blockquote><blockquote type="cite">exception of rather special-case stuff like DiscNeighborhood.<br></blockquote><blockquote type="cite">Or is ops a better place? What do you think?<br></blockquote><br>From my point of view it should be in the core, as these are basic data-structures.<br><br></div></blockquote><div>When the first 3 concrete implementations are done ok? </div><div><br></div><div>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> </div><div><br></div><div>The neighborhood hierarchy we are designing deal with pixel coordinates only and this is right. </div><div><br></div><div>Cheers</div><div>jy</div></div></body></html>