Move general registration tools into own package? #2362
Replies: 11 comments
-
I'd vote for it. In such a new library (or as part of Right now, I just committed few basic checks for |
Beta Was this translation helpful? Give feedback.
-
@raamana and @matthew-brett have you looked into this project ? https://github.com/ANTsX/ANTsPy I think a project such as scikit-image or nireg should look first at these projects. And if these are not relevant then we can look at different possibilities such as moving dipy.align (imaffine/imwarp) upstream. There are still design issues to consider but it is possible. However, for image registration maybe it is not fair to Ants as we will be competing directly against them. Doesn't feel fair to me. Now of course dipy.align is much more than image-based registration but that is a different story. I hope this explanation helps. |
Beta Was this translation helpful? Give feedback.
-
I didn’t know about ANTsPy, thanks for the pointer. From what I’ve read, simpleelastix and other non-pure python solutions (such as requiring compilation) are not easy to use i.e. they require more than one pip command to install and start using. From what I’m trying to build (for delivery to dummy users), easiest installation more or less a requirement. So if you tell me ANTsPy is easy to install and reliable and tested well, I’m a happy man with no further interest in discussing this. From a developer point of view, a pure python solution (fully pip-installable no wrappers to external dependencies) still is desirable. |
Beta Was this translation helpful? Give feedback.
-
I don't think the big C++ packages are relevant - because if you want to develop for one of those packages, you have to buy into the big C++ framework. The advantage of nireg or some other package is that the Python / Cython combination makes it much easier to see how to contribute. |
Beta Was this translation helpful? Give feedback.
-
+1 to Matthew’s point, although I’d like to note some of the high-in-demand well-tested options could still be offloaded to compiler C++ counterparts for speed. One example: Scikit-learn uses libsvm underneath! |
Beta Was this translation helpful? Give feedback.
-
Yes, sure, I think it's fine to be mainly based in Python, but do the optimizations in whatever we want, Cython, C++ ... . |
Beta Was this translation helpful? Give feedback.
-
Okay, if you think there is still value in what we have I can take the leadership and make a package only for registration. But that will be out of nipy because actually these tools that we have are more generic than the neuroworld. I am already using dipy.align for domains that are out of neuroimaging etc. Probably Ariel is doing the same. Of course I will still need help from you guys for releasing and testing. Have in mind that, after dipy release 0.14 (programmed for this or next week) we will start working on making dipy.viz a generic library. And let's say after 0.15 we can start preparations moving the registration out too. Let me know how that sounds. Dipy releases are now every 3 months. We will have to discuss a bit how the documentation will move. Let's program a zoom or hangout to discuss about this. I can make the arrangements. |
Beta Was this translation helpful? Give feedback.
-
Yes - that would be great - to take the leadership for a registration package. No problem for making it more general than neuromaging. Hangout anytime fine with me, just me know. |
Beta Was this translation helpful? Give feedback.
-
+1 for that plan from me!
…On Tue, Mar 6, 2018 at 6:23 AM, Eleftherios Garyfallidis < ***@***.***> wrote:
Okay, if you think there is still value in what we have I can take the
leadership and make a package only for registration. But that will be out
of nipy because actually these tools that we have are more generic than the
neuroworld. I am already using dipy.align for domains that are out of
neuroimaging etc. Probably Ariel is doing the same. Of course I will still
need help from you guys for releasing and testing. Have in mind that, after
dipy release 0.14 (programmed for this or next week) we will start working
on making dipy.viz a generic library. And let's say after 0.15 we can start
preparations moving the registration out too. Let me know how that sounds.
Dipy releases are now every 3 months. We will have to discuss a bit how the
documentation will move. Let's program a zoom or hangout to discuss about
this. I can make the arrangements.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1444 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAHPNtqpbPIpHM3nCQOWyipCH2jHhbHyks5tbpvXgaJpZM4ScvDg>
.
|
Beta Was this translation helpful? Give feedback.
-
Hi Matthew and all,
Unfortunately, you are right Matthew. While I haven't been able to dedicate
as much time as I wished on nireg in the past years, now I simply cannot
commit to further work - beside giving one-off help on the existing stuff,
if requested.
All the best,
Alexis
…On Mon, Mar 5, 2018 at 6:02 PM, Matthew Brett ***@***.***> wrote:
Following on from the discussion at #1442 (comment)
<#1442 (comment)> ...
This resurrects the discussion of whether we should move the general
registration tools to their own package, to make them more visible to
others doing registration, but outside Dipy.
Here's an earlier discussion, that didn't go very well : nipy/nireg#2
<nipy/nireg#2>
In particular, my own feelings about this haven't changed since I wrote
this comment: nipy/nireg#2 (comment)
<nipy/nireg#2 (comment)>
Developments since then, are that @alexis-roche
<https://github.com/alexis-roche> (please correct me if I'm wrong) is no
longer working on this stuff. Alexis, is it fair to say that you can't
commit to more development in the foreseeable future?
So, maybe nireg is the right place for general tools, but it does need
someone to be the lead on that package. I don't know enough about
registration to be that person, but I can certainly commit to grunt work
like release management.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1444>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOSOXsahbBHnCfIePzoKtrx8qr4sVa5ks5tbX25gaJpZM4ScvDg>
.
|
Beta Was this translation helpful? Give feedback.
-
Five years later: concerning the registration of the images -DiPy options for registration are not great, there are several important things missing (such as cubic interpolation for resampling the final image, ability to do 2D registration without some hacks...). I just use SimpleITK now, very easy (sort of...) and very powerful. Would it not be better just to use SimpleITK as a backend? Very easy to install in Python now |
Beta Was this translation helpful? Give feedback.
-
Following on from the discussion at #1442 (comment) ...
This resurrects the discussion of whether we should move the general registration tools to their own package, to make them more visible to others doing registration, but outside Dipy.
Here's an earlier discussion, that didn't go very well : nipy/nireg#2
In particular, my own feelings about this haven't changed since I wrote this comment: nipy/nireg#2 (comment)
Developments since then, are that @alexis-roche (please correct me if I'm wrong) is no longer working on this stuff. Alexis, is it fair to say that you can't commit to more development in the foreseeable future?
So, maybe nireg is the right place for general tools, but it does need someone to be the lead on that package. I don't know enough about registration to be that person, but I can certainly commit to grunt work like release management.
Beta Was this translation helpful? Give feedback.
All reactions