[scikit-image] Re: Is my program appropriate for Scikit-Image?

The algorithm is related, in that it uses a transformation generated from integrating a velocity flow field. But it is different in that it is not symmetric, which allows (for example) a target image to be noisy or damaged relative to an atlas image. The Ants Syn paper ( https://doi.org/10.1016/j.media.2007.06.004) is based on the formulation we referenced (LDDMM), meaning LDDMM is a bit simpler. We investigated this difference in the presence of noise here (https://doi.org/10.1090/qam/1527) and demonstrated that the symmetric version has poorer performance. The second thing is that our method does not require ITK, a large and difficult codebase. All substantial computations are either interpolation or FFT. Because of this, we don't rely on any functionality from pytorch other than FFT and interpolation, which are both available in scipy. Pytorch is only used because it makes GPU easy. We'd like to contribute, and we may have a small team of undergraduate biomedical engineering students who can contribute starting in the Fall. Would reaching out to Juan directly be the best way to get started? Thanks for getting back to me! Devin P.S. Hope you enjoyed your 4th of July! On Tue, Jul 2, 2019 at 1:30 PM Gregory Lee wrote:

Hi Devin,

I know Juan has recently expressed interest in expanding registration capabilities in scikit-image and it sounds like a well established method. How different is this algorithm from the symmetric diffeomorphic normalization (SyN) registration implemented in ANTs? That one currently has a python (+cython) based implementation in the DiPy software package, although it does not have the GPU support you mentioned.

I would take a look at https://github.com/scikit-image/scikit-image/issues/3810 for some initial discussion related to this type of thing.

Another primary concern for scikit-image is the feasibility of long-term maintenance, so we are reluctant to add things that add new dependencies or substantially complicate the build process. It would probably be most feasible to adopt a CPU-only variant that does not introduce new dependencies to scikit-image. Perhaps a GPU-specific backend could reside in a separate repository? It may be that at some point in the future, with things like NumPy's NEP-18, that GPU array support will become more feasible within scikit-image itself, but I don't think we are quite there yet.

- Greg

On Tue, Jul 2, 2019 at 12:00 PM Devin Crowley wrote:

...

I am a developer at Johns Hopkins University's Neurodata Lab and am writing a pure-python package called ARDENT that does fairly sophisticated 3D image registration. The core algorithm is based on this paper that our group produced in 2005, which has over 1200 citations and has become a standard in the field of medical image registration: Computing Large Deformation Metric Mappings via Geodesic Flows of Diffeomorphisms, available at https://link.springer.com/article/10.1023/B:VISI.0000043755.93987.aa

ARDENT works across multiple modalities (images generated by different methods, e.g. fMRI, light microscopy, etc.), and although it has convenient presets written with neuroscience applications in mind, it is fully general to all manner of image registration tasks.

I would ideally like to start a conversation but I have a few specific questions.

-- Do you think Scikit-Image is the place for a program like the one I have described?

-- Would it make more sense for our package to be incorporated into an existing Scikit-Image framework like the Transform module or included as an insular, standalone component? It seems like there is some functional overlap with Transform.estimate_transform so I suspect this might be the most logical place for ARDENT.

-- Would Scikit-Image would be comfortable with PyTorch as a dependency or as an optional dependency? The core LDDMM implementation that does ARDENT's heavy lifting utilizes PyTorch for GPU acceleration, but it could feasibly be rewritten without PyTorch.

Thank you very much, Devin Crowley JHU Research Assistant _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org

_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org