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 <devin.g.crowley@gmail.com> 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