[Mrtrix-discussion] nii conversion and general questions

[Donald Tournier]

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