|
|
|
Frequently Asked Questions | |
|---|
Please subscribe to the MRtrix mailing list and post your questions there. You can also browse through the archives to see if your question has already been addressed. Another advantage of joining the mailing list is that you get notified of any new releases.
The input data for CSD is a high angular resolution diffusion-weighted imaging (HARDI) data set. There are three main aspects of the acquisition that impact on the quality of the CSD results. In general, there will be trade-offs between the parameters concerned, meaning that there is no simple answer to this question. However, we do provide our own recommendations as part of this discussion.
In the same way, there is also no simple answer to what the minimum requirements are. It is possible to get reasonable-looking results using b=1000s/mm² and 30 DW directions, but the quality may then be questionable. In general, we would urge you to follow the recommendations given here if you intend to use CSD.
Super-CSD is actually performed in the same way as 'normal' CSD, but using a higher harmonic order (lmax) than would otherwise be possible given the data. For example, 60 directions provides enough data to perform a spherical harmonic fit up to harmonic order 8 (which requires 45 parameters), but not enough for harmonic order 10 (which requires 66 parameters) – see the table in the response function coefficient section. This means that a 60 direction data set will be analysed using straight CSD if csdeconv is performed with lmax=8 or lower, and super-resolved CSD if csdeconv is performed with lmax=10 or higher.
csdeconv will produce one such message per voxel where the CSD fails to converge. It is not unusual to get a dozen or so such messages per data set when performing a super-resolved reconstruction (see above). The voxels affected are typically not in white matter, so these failures usually won't affect any subsequent tractography.
However, if you are getting a lot of these messages, you may need to check that the CSD images are suitable. They can be loaded directly into MRview: the voxels that failed to converge will appear black. If these messages do signal a real problem, you should try to perform the CSD using a lower value of lmax. In particular, you will usually not get any such messages when performing non-super-resolved CSD (see above).
MRtrix now includes support for the NIfTI image format, allowing straightforward interaction with SPM5 and FSL (amongst others). Both of these packages provide robust functionality for coregistration. Some simple instructions for coregistration using these packages are given below.
An important point to bear in mind is that the orientation of the DWI data and any images derived from them (including the CSD results) should not be modified, since this may affect the orientation of the DW gradients with respect to the data, and hence also affect the orientation of the fibres relative to the data, which would obviously invalidate any subsequent tractography results. In practice, this means that the anatomical images should be coregistered to the DWI data, leaving the DWI data unmodified.
The first step in the coregistration procedure is to convert the images of interest to NIfTI format. The FA map appears to provide adequate contrast for coregistration with the anatomical images, so we will convert these data:
> mrconvert anat.mif anat_coreg.nii mrconvert: copying data... 100% > mrconvert fa.mif fa_coreg.nii mrconvert: copying data... 100%
The subsequent steps depend on the software package to be used.
The procedure with SPM5 is straightforward: set the FA map as the reference image, the anatomical as the source image, and coregister (estimate only) with the normalised mutual information cost function. Once the processing is done, the anat_coreg.nii image will have been re-oriented to match that of the FA map (only the header's orientation field will have been modified). The anat_coreg.nii can then be loaded into MRview instead of the original anat.mif.
anat_coreg.nii should now be coregistered with the DWI data and any tracks generated from them.
The procedure to use with FSL is slightly more complex. The FLIRT command does not produce good results if the FA map is specified as the reference. The steps required are therefore to coregister the anatomical images to the FA map, producing a 4×4 affine transform matrix. As with SPM5, the normalised mutual information cost function produces the best results. The inverse of this transform can then be applied to the anatomical images using the mrtransform command included as part of MRtrix.
> flirt -ref anat_coreg.nii -in fa_coreg.nii -cost normmi -searchcost normmi -dof 6 -omat transform.txt > mrtransform anat_coreg.nii -transform transform.txt -reference fa_coreg.nii -inverse -flipx anat_coreg.mif mrtransform: copying image data... 100%
anat_coreg.mif should now be coregistered with the DWI data and any tracks generated from them.
The tracks2prob command can be used to generate an image where each voxel contains the fraction of the total number of tracks generated that pass through that voxel. For example:
> tracks2prob tracks.tck anat.mif track_image.mif tracks2prob: generating track count image... - ok
This will produce an image of the fraction of tracks through each voxel based on the anat.mif template image.
MRtrix will produce temporary files when data pipes are used. If one of the programs in the pipeline crashes, these files will not be deleted (see here for details). If you find one or more of these files amongst your data, you can safely delete them – assuming of course that there are no currently running MRtrix programs that may be accessing the file!
If you use the Analyse image format to store your data, you may find that your FOD orientations or tractography results are not correctly aligned with the image. This is due to a limitation of the Analyse image format: it is not capable of storing the image transformation matrix. If the data were acquired in a non-axial orientation, and the DW gradient orientations were not reoriented to match the image axes, this will cause an orientation mismatch. This problem can also occur if the processing is performed in a different format that does support storing of the transform (e.g. MRtrix or NIfTI), and the results subsequently converted to Analyse format.
Another issue with the Analyse image format is the lack of a clear convention for left-right ordering. In particular, certain versions of SPM used the convention that the data were stored left to right, which is the opposite of the official Analyse application. In other versions of SPM, the convention to use for this ordering can be set by editing a configuration file. An image generated using one convention will be flipped if read assuming the opposite convention. Consequently, it impossible to guarantee that images stored in Analyse format are correctly oriented.
For these reasons, the use of Analyse images is strongly discouraged.
|
|
|
top | |
|---|