Hi Devin, and thanks for getting in touch about this!
To firm up what Greg said, I don't think there's any chance that we'll take on PyTorch as a dependency in the near future. We are actually aiming to *reduce* our dependencies at this point!
Having said that, we are definitely 100% interested in expanding scikit-image's registration capabilities, as also pointed out by Greg! And this algorithm, being standard, is definitely a good fit for the library. I'd recommend that you comment on the issue [1].
In addition to code maintenance, another concern we have is to provide a SciPy-thonic API, which means generally functions with simple inputs and outputs (arrays, tuples, lists, dicts, and strings), rather than long-lived, public-facing objects. The more sophisticated the method, the more challenging it is to develop such an API. However, I think it could live quite comfortably in the `geometric_transform` API proposed in #3810.
Looking forward to hearing more about this!
Juan.
On Wed, 3 Jul 2019, at 3:30 AM, 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.
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.
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
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