I used ITK in its C++ version during my PhD studies some years ago and I have to admit that it was very useful and fulfill my needs at that time. Since I moved to machine learning, developing in Python for scikit-learn which will probably explain some bias in my further proposal.
Last week, I come across the following example:
Of course this is doing the job. However, I found that the python programming is just looking as the C++ in some way.
In some way, thought that parameters could be pass when instantiating optimizer, loss, etc.
Even more, transform or interpolation could be replaced by string since that in a general case, the user might not need to specify inputs parameters. Somehow, some of the input could be deduced from the input images itself. So to illustrate, I thought to something like:
from pyitk.optimizer import RegularStepGradientDescent
from pyitk.metric import MeanSquaresMetric
registration = RigidRegistration(optimizer=RegularStepGradientDescent(....), loss=MeanSquaresMetric(),
transform='translation', interpolation='linear')
output = registration.fit_transform(fixed_image, moving_image)
# print the parameters of the transformation
print(registration.parameters_)
I wanted to be sure that such wrapper was possible so I drafted something there and it seems to be possible.
So I wanted to know through this post if there would be any interest of having a simplify python wrapper, which of course does not allow for all the possibility of ITK or SimpleITK.
Filters, including the v4 registration method, can be called in a procedural way
Filters can be called with their options given as keyword parameters
Even more, transform or interpolation could be replaced by string since that in a general case, the user might not need to specify inputs parameters.
In practice, many of the transforms have parameters, e.g. the B-spline grid size or the center of rigid transforms, and it is rare to change the interpolator from the default linear interpolator.
I will give a pass at updating the example to take advantage of the wrapping’s capabilities and I am interested to hear what you think. Also, there are other improvements that can be made on the C++ side in that example, too.
I am also interested if you have any thoughts about improving itkExtras, too.
There are a number of features in ITK’s Python wrapping that are not well known. For example,
Filters can deduce their type from their inputs
Filters, including the v4 registration method, can be called in a procedural way
Filters can be called with their options given as keyword parameters
So it seems that all features are already there which is great. So probably my only concern is how to make it discoverable for a new user. I’ll give a try to explore those.
In practice, many of the transforms have parameters, e.g. the B-spline grid size or the center of rigid transforms, and it is rare to change the interpolator from the default linear interpolator.
I was thinking about rigid transformation for the moment. This is true that using B-spline or TPS would require an instance.
I am also interested if you have any thoughts about improving itkExtras, too.
The functions are helpful for sure. My issue is more on the documentation side and how to make those functions easily discoverable to a user. I would think to find it in the ITKPythonPackage readthedocs in an API documentation page which does not seem to be the case.
Also, spacing, origin, etc. return ITK type and I am wondering if it would not be easier to return directly numpy array. Somehow, IMO python user would expect those type and knows to deal with those types for sure.
Yes, good idea – there is definitely room for improvement here. Your thoughts and help are welcome and appreciated!
True. We should add the API documentation for at least some of the content in ITK/Wrapping/Generators/Python/itk*.py to the ITKPythonPackage ReadTheDocs documentation. The rest of the toolkit re-uses the Doxygen documentation in the Python wrapping help strings.
The current ITK Python ReadTheDocs should indeed be updated to expose the possibility to use function calls to run filters. I guess this should be on my to-do list.
