[Mrtrix-discussion] nii conversion and general questions

Tue Sep 9 15:58:24 PDT 2008

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
>>>
>>>
>>
>>
>>
>>
>
>

-- 
Jacques-Donald Tournier (PhD)
Brain Research Institute, Melbourne, Australia
Tel: +61 (0)3 9496 4078