[Mrtrix-discussion] nii conversion and general questions

Tue Sep 9 16:49:47 PDT 2008

Hi Donald,

yep, always having fun...
My brain forgot to tell me about the rotation-about-an-axis-thing. What 
you say makes perfect sense. Thanks!

Kerstin

Donald Tournier wrote:
> Hi Kerstin,
>
> I see you're still having fun...
>
>   
>> I think the bvecs are not just rotated. They draw angles between 0.68 and
>> 4.29 degrees (mean 3.21, std 0.91). I have a feeling that this is more than
>> one would expect due to "rounding errors" (6 decimal places v 2 decimal
>> places). Possibly they are sorted differently (I know that repetitions are
>> sorted differently: mrtrix has repetition 1 complete, then repetition 2
>> complete, while MRIconvert mixes so that you end up having a hard time
>> averaging...) I would have liked to only use mrtrix for the image
>> conversion, but since I don't know what the FSL reference frame is, I'll
>> better stay on the safe side and use MRIconvert for FSL (which most FSL
>> users do) and mrconvert for mrtrix.
>>     
>
> If the two bvecs files are indeed rotated with respect to each other,
> you would expect to see a range of angles like you do. This is due to
> the fact that the vectors are rotated about a particular axis. Those
> vectors that are closely aligned with the axis of rotation will barely
> be affected, while those that are almost perpendicular to the axis of
> rotation will be most affected. I hope I'm making sense...
>
> In any case, if most FSL users rely on MRIconvert, I would stick to
> that for your FSL analyses, and stay on the safe side like you say.
>
>
>   
>> I'm really sorry, but I still can't get a proper output out of
>> find_SH_peaks. This is what I did:
>> gendir 100 dir100.txt
>> find_SH_peaks CSD6.mif dir100.txt SH_peaks_CSD6.mif
>> In mrview, SH_peaks_CSD6.mif appears empty.
>> What am I doing wrong?
>>     
>
> OK, I can confirm this is a bug, you're not doing anything wrong.
> Sorry about that, I'll have a look into it when I get the chance and
> fix it up.
>
>
>   
>> The mrconvert -datatype option to convert to nifti works nicely, thank you!
>>     
>
> Glad to hear it.
> Cheers!
>
> Donald.
>
>
> PS: could I ask you to make sure you use the 'Reply to All' option
> when replying to a message from the mailing list? Otherwise it only
> gets sent to the original sender, not to the actual list. Thanks!
>
>
>   
>> Cheers
>> Kerstin
>>
>>
>> Donald Tournier wrote:
>>     
>>> Hi Kerstin,
>>>
>>> If the two bvecs files are simply rotated with respect to each other,
>>> this shouldn't have any effect on the FA maps (the FA is rotationally
>>> invariant). The directions will on the other hand be affected, by just
>>> the same amount of rotation (3° in your case). However, I would urge
>>> you to use the appropriate bvecs file as a matter of routine. 3
>>> degrees may not seem like much, but it might be just enough to throw
>>> you off course. Also, it's best to develop some good habits now: this
>>> may be OK-ish for this data set, but it might be completely
>>> inappropriate for a different data set.
>>>
>>> About the FSL data type error, I've also had issues with FSL only
>>> supporting a subset of the allowed NIfTI data types. You can try
>>> giving mrconvert an additional option when converting to NIfTI to
>>> change the data type to something supported, e.g. "-datatype int16" or
>>> "-datatype float32" - whichever works (there is a list of all the
>>> supported data types in the MRtrix documentation, after the supported
>>> image formats). Your command might then look something like this:
>>>
>>>
>>>       
>>>> mrconvert anat.mif -datatype int16 anat.nii
>>>>
>>>>         
>>> FSL should then be able to access that image without any problem.
>>>
>>> Finally, to get your FOD orientations: you can use the 'gendir'
>>> command to generate a set of directions suitable for find_SH_peaks.
>>> For this application, I guess 100 directions is ample. This command
>>> should do the trick:
>>>
>>>
>>>       
>>>> gendir 100 dir100.txt
>>>>
>>>>         
>>> Cheers!
>>>
>>> Donald.
>>>
>>>
>>> On Fri, Sep 5, 2008 at 1:41 PM, Kerstin Pannek <k.pannek1 at uq.edu.au>
>>> wrote:
>>>
>>>       
>>>> Hi Donald
>>>>
>>>> thanks for your reply.
>>>>
>>>> I had a closer look at the different bvecs now, and comparing them, I
>>>> found
>>>> an average difference of about 3 degrees between them, which does not
>>>> sound
>>>> like a huge difference to me. I looked at the FA maps generated using the
>>>> different bvecs, and at first glance they look very similar.
>>>>
>>>> I then ran into a problem trying to convert dicom images to nii using
>>>> mrconvert. I tried opening the *.nii images with fslview and got an error
>>>> message: "data type not supported". When I try using fslmaths on the
>>>> dataset, I got this error: "Fslread: DT 512 not supported: Success". It
>>>> is
>>>> possible to use some fsl commands (like eddy current correction). My
>>>> current
>>>> workaround is to split and then merge the files. Does this have something
>>>> to
>>>> do with the image conversion or do you think it is a bug in the fsl
>>>> software?
>>>>
>>>> I have another question about find_SH_peaks. The documentation says the
>>>> usage is
>>>> find_SH_peaks [ options ] SH directions ouput
>>>> where directions is the set of directions to use as seeds for the peak
>>>> finding. What input should I use for this? I guess I'm not using it
>>>> right,
>>>> because the output I get is a dataset of 9 volumes, where only the first
>>>> 3
>>>> volumes have voxels with values other than 0, and these are nicely lined
>>>> up
>>>> in a corner of the volumes...
>>>>
>>>> Thanks again for you help!
>>>> Kerstin
>>>>
>>>> Donald Tournier wrote:
>>>>
>>>>         
>>>>> Hi Kerstin,
>>>>>
>>>>> Glad to hear the new release will be useful. In answer to your
>>>>> questions:
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> 1) I noticed that the transformation in the header file when converting
>>>>>> from
>>>>>> *.nii is not identity any more (as is used to be when converting from
>>>>>> ANALYZE). I assume I can therefore not use the bvecs I use for
>>>>>> FSL-analysis?
>>>>>> Would I get the gradient scheme directly from DICOM then? On the other
>>>>>> hand,
>>>>>> if I would use mrconvert to convert from *.mih to *.nii, could I then
>>>>>> use
>>>>>> the *.mih gradient scheme for FSL-analysis? Or do I need 2 sets of
>>>>>> bvecs,
>>>>>> one for mrtrix, one for FSL?
>>>>>>
>>>>>>
>>>>>>             
>>>>> This is actually the main reason to implement NIfTI support: the
>>>>> Analyse header has no way of storing the transformation. What you see
>>>>> in that field when reading an Analyse image (or any image derived from
>>>>> one) using MRtrix (or FSL) is a default transform (the identity)
>>>>> assigned by the software rather than read from the headers. Any image
>>>>> derived or converted from an Analyse image will be assigned this
>>>>> default header. I would recommend avoiding the Analyse format for that
>>>>> reason.
>>>>>
>>>>> Whether you can use the same bvecs is a slightly trickier question to
>>>>> answer. As far as I know, the bvecs I get from the DICOM headers are
>>>>> specified relative to real space, and this is what MRtrix also
>>>>> assumes. I'm not sure how FSL works from that point of view. If your
>>>>> DW images are all acquired as straight axials, then there should be no
>>>>> problem using the same bvecs for both (since there is no rotation
>>>>> between the Analyse & NIfTI images, just translation). On the other
>>>>> hand, if they are tilted, then I'm guessing that you should NOT be
>>>>> using the bvecs obtained from MRtrix to process Analyse images with
>>>>> FSL (or MRtrix for that matter). I have no idea how FSL deals with
>>>>> NIfTI images if there is any rotations in the transform.
>>>>>
>>>>> In short, I'm not sure what bvecs you should use with FSL. On the
>>>>> other hand, you should definitely use the DICOM bvecs for MRtrix
>>>>> processing, if they are available. Remember that if you intend to
>>>>> coregister your data, you should leave the DWI and related images
>>>>> (i.e. FA, CSD, etc) unmodified - you should register other images to
>>>>> them, rather than the other way around. There's some discussion about
>>>>> that in the Frequently Asked Questions in the new docs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> 2) During CSD computation, I sometimes get a message "csdeconv: failed
>>>>>> to
>>>>>> converge". Should I be worried about that and reduce lmax? The
>>>>>> computation
>>>>>> continues after this message, and the results look reasonable to me. My
>>>>>> dataset is 65 directions, b3000, 2 averages, lmax 8. This is the
>>>>>> command
>>>>>> I
>>>>>> ran:
>>>>>>
>>>>>> $ csdeconv ../data/data.mih -grad ../data/encoding.b -lmax 8
>>>>>> response.txt
>>>>>> -mask ../data/nodif_brain_mask.mih CSD8.mih
>>>>>>
>>>>>> csdeconv: performing constrained spherical deconvolution...
>>>>>>  63%csdeconv:
>>>>>> failed to converge
>>>>>> csdeconv: performing constrained spherical deconvolution... 100%
>>>>>>
>>>>>>
>>>>>>             
>>>>> This is also now discussed in the Frequently Asked Questions. If you
>>>>> only get one message, this means only one voxel is affected, and is
>>>>> unlikely to be in white matter anyway. I wouldn't worry too much about
>>>>> that unless you get dozens of these messages per data set.
>>>>>
>>>>> There are actually two different reasons why csdeconv might fail to
>>>>> converge. One is that it has gone over the maximum number of
>>>>> iterations (default is 50). This usually happens because it is
>>>>> oscillating between two equally suitable solutions. In this case, you
>>>>> end up with whichever solution was last computed. The other reason is
>>>>> that it failed to identify enough negative directions to make the
>>>>> problem tractable. This can only happens when performing a
>>>>> super-resolved reconstruction (in your case, lmax >= 10). In this
>>>>> case, that voxel is left blank - you end up with a hole in the data.
>>>>> Thankfully, these problems tend to happen in non-brain or grey matter
>>>>> voxels, so are not usually a problem for tractography. However, if you
>>>>> find you get lots of these messages, there may be something going on
>>>>> that needs to be investigated further.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> 3) Is it possible to extract the fibre orientation and fraction
>>>>>> information
>>>>>> from the CSD-file?
>>>>>>
>>>>>>
>>>>>>             
>>>>> The command 'find_SH_peaks' is what you're looking for.
>>>>>
>>>>> Hope that helps.
>>>>> Cheers,
>>>>>
>>>>> Donald.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> Mrtrix-discussion mailing list
>>>> Mrtrix-discussion at www.nitrc.org
>>>> http://www.nitrc.org/mailman/listinfo/mrtrix-discussion
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>>     
>
>
>
>   