Greetings! I would like to start a project working on image registration algorithms in python. I am proposing a new sci-kit called scikit-morph because I believe registration is too specific for inclusion in scipy directly. My short term goals are to: 1) implement a basic image registration framework - perhaps similar to the design used by ITK. 2) Implement image resampling methods for use in the optimisation (c++). 3) Use py.test to thoroughly test all code. I have started by setting up a github project, here: http://github.com/nfaggian/scikit-morph How I can get this going in a way that meshes well with existing scikit structures? I have looked at both the image and learn scikits, is it a matter of simply using the same directory structures?? Any help on getting a skeleton project going would be great - also very open to people joining in - please email me directly if you would like to help out! Kind Regards, Nathan Faggian
On Sat, May 14, 2011 at 06:50:43PM +1000, Nathan Faggian wrote:
I would like to start a project working on image registration algorithms in python. I am proposing a new sci-kit called scikit-morph because I believe registration is too specific for inclusion in scipy directly.
You might want to coordinnate with Alexis Roche, who has been doing similar work in Nipy. Cheers, Gael
On Sat, May 14, 2011 at 10:50 AM, Nathan Faggian <nathan.faggian@gmail.com>wrote:
Greetings!
I would like to start a project working on image registration algorithms in python. I am proposing a new sci-kit called scikit-morph because I believe registration is too specific for inclusion in scipy directly.
Is there a reason not to include this in scikits.image instead? It fits well there, you'd probably get more help and you wouldn't have to worry about setting up a new project structure. Cheers, Ralf
My short term goals are to:
1) implement a basic image registration framework - perhaps similar to the design used by ITK. 2) Implement image resampling methods for use in the optimisation (c++). 3) Use py.test to thoroughly test all code.
I have started by setting up a github project, here:
http://github.com/nfaggian/scikit-morph
How I can get this going in a way that meshes well with existing scikit structures? I have looked at both the image and learn scikits, is it a matter of simply using the same directory structures??
Any help on getting a skeleton project going would be great - also very open to people joining in - please email me directly if you would like to help out!
Kind Regards,
Nathan Faggian
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi, I am really glad to get some responses so quickly. Gael: I will follow up with Alexis - thats a great idea! Ralf: I would still like to push the idea of having a separate scikit for this work. What I would like the scikit to become is a collection of non-linear image registration algorithms, which is different to the warping that is described by the scikit image library. Particularly, I would also like the scikit to support the design and evaluation of registration algorithms . Actually, maybe it is better that the scikit is called scikit-register? Something a bit different... Does anyone else see some duplication between the scipy.ndimage and scikit.image? Seems like morphological operators are defined in both? -N On 14/05/2011, at 7:57 PM, Ralf Gommers wrote:
On Sat, May 14, 2011 at 10:50 AM, Nathan Faggian <nathan.faggian@gmail.com> wrote: Greetings!
I would like to start a project working on image registration algorithms in python. I am proposing a new sci-kit called scikit-morph because I believe registration is too specific for inclusion in scipy directly.
Is there a reason not to include this in scikits.image instead? It fits well there, you'd probably get more help and you wouldn't have to worry about setting up a new project structure.
Cheers, Ralf
My short term goals are to:
1) implement a basic image registration framework - perhaps similar to the design used by ITK. 2) Implement image resampling methods for use in the optimisation (c++). 3) Use py.test to thoroughly test all code.
I have started by setting up a github project, here:
http://github.com/nfaggian/scikit-morph
How I can get this going in a way that meshes well with existing scikit structures? I have looked at both the image and learn scikits, is it a matter of simply using the same directory structures??
Any help on getting a skeleton project going would be great - also very open to people joining in - please email me directly if you would like to help out!
Kind Regards,
Nathan Faggian
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Sat, May 14, 2011 at 11:35:30PM +1000, Nathan Faggian wrote:
Ralf: I would still like to push the idea of having a separate scikit for this work.
I agree with you: scikits.image is more 2D related. In addition, registration as a fairly big endeavior, and tackling it by itself will probably increase the chances of success. G
What I would like the scikit to become is a collection of non-linear image registration algorithms, which is different to the warping that is described by
Hi Nathan Nathan Faggian <nathan.faggian <at> gmail.com> writes: the scikit image library. Particularly, I would also like the scikit to support the design and evaluation of registration algorithms . Actually, maybe it is better that the scikit is called scikit-register? Image registration is definitely on the cards for scikits.image. I already have some rigid registration algorithms implemented at http://github.com/stefanv/supreme but I'd like to round those off and make them more robust. Currently, there are feature-based and dense methods.
Does anyone else see some duplication between the scipy.ndimage and scikit.image? Seems like morphological operators are defined in both?
We try not to duplicate functionality unless necessary. Unfortunately, it is hard to maintain scipy.ndimage, so sometimes we rewrite or wrap algorithms as appropriate. The buffered approach ndimage uses to do filtering is actually very efficient, so we build on that until we have a better replacement (we're working on different backends now, such as OpenCL, Theano etc.) Regards Stéfan
Hi Stefan, Your supreme project looks great! A couple of years ago I dabbled with image registration for video stabilisation and the work you have done by implementing the Ransac algorithm and linear registration is also suitable for that application. Do you also know about the X84 rejection rule? I hope that I didn't sound too critical when I pointed at duplication, I really think the image scikit is great and I am keen to see how you go with different back ends to speed up computation. In scikit-morph I plan to implement dense non-linear image registration methods, for example: http://www.fmrib.ox.ac.uk/fsl/fnirt/index.html I am part way through implementing the approach used by FNIRT and once I get this working in 2D I will make some noise on the mailing-list. So far I have had a bit of fun looking into cython to speed up image sampling. -N On 21/05/2011, at 11:35 PM, Stefan van der Walt wrote:
Hi Nathan
Nathan Faggian <nathan.faggian <at> gmail.com> writes:
What I would like the scikit to become is a collection of non-linear image registration algorithms, which is different to the warping that is described by the scikit image library. Particularly, I would also like the scikit to support the design and evaluation of registration algorithms . Actually, maybe it is better that the scikit is called scikit-register?
Image registration is definitely on the cards for scikits.image. I already have some rigid registration algorithms implemented at
http://github.com/stefanv/supreme
but I'd like to round those off and make them more robust. Currently, there are feature-based and dense methods.
Does anyone else see some duplication between the scipy.ndimage and scikit.image? Seems like morphological operators are defined in both?
We try not to duplicate functionality unless necessary. Unfortunately, it is hard to maintain scipy.ndimage, so sometimes we rewrite or wrap algorithms as appropriate.
The buffered approach ndimage uses to do filtering is actually very efficient, so we build on that until we have a better replacement (we're working on different backends now, such as OpenCL, Theano etc.)
Regards Stéfan
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi Nathan On Sun, May 22, 2011 at 2:10 AM, Nathan Faggian <nathan.faggian@gmail.com> wrote:
Your supreme project looks great! A couple of years ago I dabbled with image registration for video stabilisation and the work you have done by implementing the Ransac algorithm and linear registration is also suitable for that application. Do you also know about the X84 rejection rule?
It vaguely rings a bell when thinking back to KLT's "Good Features to Track", but if you could give me a better pointer that'd be great. I implemented a couple of early termination rules for RANSAC, such as LO-RANSAC, etc.
I hope that I didn't sound too critical when I pointed at duplication, I really think the image scikit is great and I am keen to see how you go with different back ends to speed up computation.
Not at all; we welcome good criticism--especially if it leads to more conversations (and hopefully more contributors)!
In scikit-morph I plan to implement dense non-linear image registration methods, for example:
http://www.fmrib.ox.ac.uk/fsl/fnirt/index.html
I am part way through implementing the approach used by FNIRT and once I get this working in 2D I will make some noise on the mailing-list. So far I have had a bit of fun looking into cython to speed up image sampling.
From my side, the super-resolution toolbox is released under a BSD
Since I'd also like to extend the registration capabilities in scikits.image, would you be open to having your work included there as well? One advantage would be that your code is then distributed with EPD and Python(x,y); both packages that reach a large audience. license and you are more than welcome to use any of the code in it as you see fit. Regards Stéfan
participants (5)
-
Gael Varoquaux -
Nathan Faggian -
Ralf Gommers -
Stefan van der Walt -
Stéfan van der Walt