I think this would make sense, since neighborhoods are conceptually based on ROIs. Additionally, if we could separate the “ROI-like” components from the neighborhood implementations we’d essentially have the discrete space equivalents for ROIs. Furthermore, imglib2-algorithms already depends on imglib2-roi and they’re both 0.x so now would be the time to make such a change.

Personally I think this is a great idea. In my view, imglib2-algorithm is intended to store algorithm implementations built on ImgLib2, whereas imglib2-roi is intended for data structures to facilitate region-oriented processing and algorithm development.

I also think this is a good idea. I would wait until the work @dietzc and me started at the hackathon is complete. Then I hope it will be clearer where the neighborhoods fit into the picture (making it clearer which package they should go into etc…)

If for some reason it would be convenient to just move the neighborhoods right now, thats also fine with me. I agree that the imglib2-roi artifact is a more fitting place that algorithms. (only that they might then later move under a different package, so we have to fix things twice instead of once.)