|Please use this identifier to cite or link to this publication: http://hdl.handle.net/1926/1291|
Our goal was to determine best practices for registering 3D rigid multimodal MRI of the human brain. A version of the current program is employed here at PINC daily for automated processing of acquired brain images.
This project is managed on the NITRC site. http://www.nitrc.org/projects/multimodereg/
On the NITRC website, you can acquire the latest source code via SVN, or by downloading a compressed file which is generated every night. Binary versions are also available.
The authors present an integrated solution for registering brain MRI data. In my opinion, this paper is a nice example of using generic registration components of ITK to engineer an effective application-specific tool. The authors make an effort to identify the parameters that work out-of-the-box to achieve automated registration with minimum user involvment, while providing flexibility to tune the process for the experienced users. The project is free open source, one of the few of this kind, and is work under continuous development and improvement (the project is represented on NITRC).Hypothesis:
The implicit hypothesis is that good quality automated registration of brain MRI with the default parameters is achievable by carefully tuning the registration parameters, and designing a customized registration workflow.Evidence:
Reportedly, the package is used routinely to process brain image data at the author's lab. The authors do not present a comprehensive evaluation of the developed tool, but rather present an overview of how the tool can be used, and its major features.Open Science:
The authors provide the source code, and document the major features and motivation behind their implementation. There is one example of the registration, which is however appears to be for illustration purposes.Reproducibility:
I downloaded the latest (at the time) version of the code from NITRC (rev. 234). I used the code as a plugin in 3D Slicer (http://slicer.org). The plugin did not work right away, and I had to do some modifications in the code and compile process to be able to use it in Slicer (no changes in the algorithmic part).
I applied BRAINSFit to the set of longitudinal MRI contrast-enhanced T1 images with developing pathology. I was able to achieve good registration results with minimum changes to the default parameters. The results of the evaluation together with the comparative assessment with the FSL FLIRT tool (http://www.fmrib.ox.ac.uk/fsl/flirt/overview.html) are available here, this is work in progress:
The specific changes to the default settings used in BRAINSFit 3D Slicer module that I did are the following:
1) use CenterOfHead transform initialization
2) use ROIAUTO mode to discard the image background while sampling the similarity metric
3) reduced the number of samples from 1500 to 200 to reduce the execution time.
I mostly evaluated the capabilities of the tool using Rigid>ScaleVersor3D>Affine transformation pipeline, not BSpline transformation.Use of Open Source Software:
The authors set a very good example of using effectively available open source tools (ITK, in the present article, and 3D Slicer, by developing a plugin available through 3D Slicer extensions mechanisms and through NITRC). I greatly appreciate the effort authors put in developing this tool, and in preparing its public release.
The authors introduce a new transform, 9 DOF ScaleVersor3DTransform, which follows the ITK standards, and is a very nice addition to the already implemented transforms in ITK. In my opinion, this is a nice piece that could be integrated into ITK, since it simplifies the registration pipeline. Moreover, some publications suggest 9 DOF registration for longitudinal data analysis to account for scanner mis-calibration, resulting in the incorrect voxel sizes in the acquired images.Open source Contributions:
The code I used (NITRC rev.234) was in usable form, with the exception that I needed to put some effort to make Slicer plugin work. This problem might have been fixed by now, since I reported the problem to the developers, together with the needed patch.
The plugin is very intuitive to use, since the authors provide detailed comments in GUI tooltips explaining the meaning of the parameters, and the guidelines on their tuning. As the extra material, see BRAINSFit Slicer plugin page as part of NA-MIC collaboration here: http://www.na-mic.org/Wiki/index.php/BRAINSFit
It took me couple of hours to understand and fix the issues with the BRAINSFit Slicer plugin.Code Quality :
The authors provide the source code.
Unfortunately, not all of the code is easy to read. The major part of the code is rather confusing, since the authors use one single file, with a huge function, to assemble the registration pipeline. The actual registration code for all transforms except BSpline is contained in a .tmpl file, which is obscure, but it works.
Nevertheless, when needed, I was able to introduce modifications to the code to add extra functionality that I needed (saving of the automatically detected ROIs in the ROIAUTO mode).
At the same time, the generic component that I believe should be considered for inclusion in ITK, ScaleVersor3DTransform, is written very cleanly, following ITK coding and formatting guidelines.Quality of the data :
I would recommend considering using this package as an alternative to the commonly used non-open-source tools, like FSL, for any studies involving brain MRI registration. Based on the evaluation I performed, the TRE relative to the result achieved with FSL FLIRT on 9 datasets was consistently in the sub-voxel range (see the reference to the study materials above).Free comment :
With the settings that I used to run the code (CentersOfHead transform initialization and ROIAUTO mask generation), execution takes long time -- around 12 minutes on head MRI data. It turns out, that most of the time, around 90% is spent in the initialization and ROI selection. Can performance of these steps be improved?
I found the functionality of transform initialization and ROI selection to be very interesting on their own. I would suggest that authors present those in separate tools, and possibly discuss the algorithms they use in more detail. Of course, these can be understood from the code, but it would be nice to get a glimpse on authors' motivation in implementing them.
The functionality I added to the code was to save the automatically detected ROIs, so that I can visually assess their quality. The patch implementing this functionality was submitted to the authors.
Comment by :
Comment by :
Comment by :
|Categories:||Multi-modality registration, Registration|
|Keywords:||Registration, Mutual Information|
|Toolkits:||ITK, CMake, VTK|
Linked Publications more
Diffeomorphic Demons Using ITK's Finite Difference Solver Hierarchy
by Vercauteren T., Pennec X., Perchant A., Ayache N.
Small Hole Filling in ITK
by Doria D.
Send a message to the author