[Mrtrix-discussion] nii conversion and general questions

[Kerstin Pannek]

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