[Mrtrix-discussion] transform and normalise tracks

[Ping-Hong Yeh]

Hi Donald,

Our DICOM header has wrong gradient table because we added several b0
images inbetween but the sequence output  the original diffusion
gradient directions used by the GE vendor. For this reason, I need to
use the "-grad" flag for specifying correct gradient table in the
commands.


Here is waht I did,

mrconvert J:\Data\DTI\DICOM\NCNC0017 dwi.mif
dwi2tensor dwi.mif -grad J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt
dt_mrtrix_orig.mif
tensor2FA dt_mrtrix_orig.mif fa_mrtrix_orig.mif
tensor2FA dt_mrtrix_orig.mif - | mrmult - b0mask.nii fa_mrtrix_brain_orig.mif
tensor2vector dt_mrtrix_orig.mif - | mrmult - fa_mrtrix_orig.mif ev_orig.mif
erode b0mask.nii  - | erode - - | mrmult fa_mrtrix_orig.mif - - |
threshold - -abs 0.6 sf_orig.mif
estimate_response dwi.mif sf_orig.mif -lmax 6 -grad
J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt response_lmax6_orig.txt
-info
csdeconv dwi.mif response_lmax6_orig.txt -lmax 6 -mask b0mask.nii
-grad J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt CSD6_orig.mif
gen_WM_mask dwi.mif -grad J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt
b0mask.nii wm_orig.mif
threshold wm_orig.mif -percent 0.01 wm_mask_orig.nii
streamtrack SD_PROB CSD6_orig.mif -seed wm_orig.mif  -mask
wm_mask_orig.nii  -number 500000 wmtracks_sdprob_csd6_500000_orig.tck
tracks2prob wmtracks_sdprob_csd6_500000_orig.tck  -template dwi.mif
-vox 0.5 -fraction wmtrack_sdprob_csd6_500000frac_vox0.5_orig.nii


Thank you,

Ping

On Fri, Jan 14, 2011 at 8:45 PM, Donald Tournier
<d.tournier at brain.org.au> wrote:
> Hi Ping,
> Sounds strange. Not sure I can really help without more detailed
> information. Could you send me the transcript of the commands that you
> typed, from start to finish? Maybe I can spot where things may have gone
> funny...
> Cheers,
> Donald.
>
> On 15 January 2011 03:27, Ping-Hong Yeh <pinghongyeh at gmail.com> wrote:
>>
>> Hi Donald,
>>
>>  Thank you again for the reply.
>>
>> The reason using the NIFTI instead of DICOM is because we would like
>> to correct EPI distortion using fieldmap beforehand.
>>
>> Anyhow, I also input the DICOM files using mrconvert and the result of
>> TDI image is similar to the one using NIFTI as the input. I still
>> think the TDI using ANLYZE one looks right, but do not understand why
>> there is such a huge difference.
>>
>> Any further comment? Thanks.
>>
>> Ping
>>
>> On Thu, Jan 13, 2011 at 2:35 AM, Donald Tournier
>> <d.tournier at brain.org.au> wrote:
>> > Hi Ping,
>> > I'm guessing your issues are due to the fact that ANALYZE does not store
>> > the
>> > transformation matrix (i.e. the directions of the axes and location of
>> > the
>> > origin with respect to real/scanner space), whereas NIfTI does. This is
>> > one
>> > of the reasons I urge everyone to stay well away from ANALYZE format
>> > images
>> > (the other being that left/right ordering is ill-defined).
>> > If you convert a NIfTI image with a proper transformation matrix to
>> > ANALYZE,
>> > that information is lost. I guess the overlay function in FSLView
>> > operates
>> > on a voxel-by-voxel basis - i.e. that the transformation information is
>> > ignored, and only voxel coordinates within the imaging volume are taken
>> > into
>> > account. This is not the case for MRtrix: each voxel is displayed in the
>> > correct location, according both to its voxel coordinate within the
>> > imaging
>> > volume, and the transformation information. Note that with ANALYZE
>> > images,
>> > MRtrix will insert a default identity transform (no rotation, origin in
>> > the
>> > middle of the dataset). That should explain the mismatch in the overlay.
>> > If
>> > you want to double-check this, use 'mrinfo' on both images, and see if
>> > the
>> > transforms differ.
>> > On the other hand, I have no idea why the TDI maps are so different. I'm
>> > assuming you have to supply your own gradient encoding, and that you're
>> > using the same encoding file in both cases? Other than strange effects
>> > due
>> > to different gradient encodings, I have no idea what the issue might be.
>> > One
>> > possibility is that you're using a gradient table suitable for analysis
>> > using FSL, where the gradient directions are supplied with respect to
>> > the
>> > image axes. Since MRtrix assumes that they are supplied with respect to
>> > real/scanner space, if there is a significant rotation component in the
>> > transformation, the tracking will be affected. Might explain why the
>> > tracking is OK with ANALYZE (the transform has been discarded - no
>> > rotation)
>> > but not with NIfTI. Although there doesn't seem to be a huge rotation
>> > between them judging from your screenshot...
>> > On a final note, if you have access to the DICOM data, why not use
>> > MRtrix to
>> > do the conversion for you? If you convert to MRtrix image format (.mif),
>> > you
>> > will have the correct transform information, the DW gradient table will
>> > be
>> > inserted in the header, and you shouldn't have any problems of this
>> > kind.
>> > Hope that sort things out for you.
>> > Cheers,
>> > Donald.
>> >
>> > On 12 January 2011 15:24, Ping-Hong Yeh <pinghongyeh at gmail.com> wrote:
>> >>
>> >> Hi Donald,
>> >>
>> >>  Thank you for the detailed explanation.
>> >>
>> >> Another question about the input data format.
>> >>
>> >> First, I have the same DWI data saved as NIFTI or ANALYZE. The  NIFTI
>> >> was converted from DICOM originally using dcm2nii and then to ANALYZE
>> >> using FSL fslchfiletype. Both images are aligned well while viewing
>> >> using FSLview (see attached  Screenshot_fslview.png); but there is a
>> >> significant translation while viewing using mrview
>> >> (mrview_screen.jpg).
>> >>
>> >> I then processed both data and created the whole brain TDI images, but
>> >> the results are quite different (see tdi_analyze.jpg and
>> >> tdi_nifti.jpg).  It appear the TDI image by using ANALYZE is what TDI
>> >> is supposed to be looked like although now it does not align with
>> >> original NIFTI data, which has made the previous co-registration
>> >> matrices useless.
>> >>
>> >>
>> >> Thank you,
>> >>
>> >> Ping
>> >>
>> >>
>> >> On Mon, Jan 10, 2011 at 8:14 AM, Donald Tournier
>> >> <d.tournier at brain.org.au> wrote:
>> >> > Hi Ping,
>> >> > Unfortunately, the 'normalise_tracks' command can't be used to apply
>> >> > a
>> >> > 4x4
>> >> > affine transform: it's designed to apply a non-linear warp to the
>> >> > track
>> >> > data. The warp information should be supplied as a 4D image, where
>> >> > the
>> >> > values for each voxel are set to the coordinates that this voxel maps
>> >> > to. To
>> >> > help generate the warp, there is a utility called 'gen_unit_warp',
>> >> > which
>> >> > will generate a 'no warp' image (i.e. each voxel contains its own
>> >> > location),
>> >> > to which you can apply the relevant inverse warp using whatever
>> >> > software
>> >> > package you use for your normalisation (FSL, SPM, etc). You can then
>> >> > feed
>> >> > the result to 'normalise_tracks' as the transform image.
>> >> > Getting the details can be quite tricky, so here is an example using
>> >> > SPM8,
>> >> > using the warp computed by normalising a T1 image (anat.nii)
>> >> > previously
>> >> > coregistered with the FA:
>> >> > Assuming you are normlising to the default T1 template image (T1.nii)
>> >> > supplied with SPM8, start by generating a unit warp image using that
>> >> > as
>> >> > a
>> >> > template:
>> >> > $ gen_unit_warp /opt/SPM8/templates/T1.nii warp-[].nii
>> >> > Note that the output image has been specified as a multi-file NIfTI,
>> >> > so
>> >> > this
>> >> > should produce the files warp-1.nii, warp-2.nii & warp-3.nii.
>> >> > Then estimate the warp you're interested in applying. In SPM8, select
>> >> > SPM->Spatial->Normalise->Estimate in the batch editor, specify the
>> >> > anat.nii
>> >> > as the source image, and T1.nii as the template, and run. This will
>> >> > generate
>> >> > the warp information as a "anat_sn.mat" file.
>> >> > Then, apply the inverse warp to your warp-*.nii images: select
>> >> > SPM->Util->Deformations in the batch editor, choose "New: inverse" as
>> >> > the
>> >> > composition, then "New: Imported _sn.mat" as its composition,
>> >> > "anat_sn.mat"
>> >> > as the parameter file, and your fa.nii as the "image to base inverse
>> >> > on".
>> >> > Specify all 3 wrap-*.nii in the "apply to" field, and run.
>> >> > This should generate 3 new files: wwarp-*.nii, which can be used
>> >> > directly in
>> >> > "normalise_tracks":
>> >> > $ normalise_tracks tracks.tck wwarp-[].nii tracks_normalised.tck
>> >> > Obviously the steps would be very different depending on the
>> >> > normalisation
>> >> > package you're using, but the idea would be the same.
>> >> > Hope that clarifies things a little.
>> >> > Cheers,
>> >> > Donald.
>> >> >
>> >> > On 7 January 2011 15:47, Ping-Hong Yeh <pinghongyeh at gmail.com> wrote:
>> >> >>
>> >> >> Hello all,
>> >> >>
>> >> >>  I would like to transforming the tracks to the template space, but
>> >> >> not sure how to apply the transformation matrix (4 by4 Ascii) using
>> >> >> "normalise_tracks".
>> >> >> How should the normalisation map be created?   Thanks.
>> >> >>
>> >> >> Ping
>> >> >> _______________________________________________
>> >> >> 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
>> >> >
>> >
>> >
>> >
>> > --
>> > Jacques-Donald Tournier (PhD)
>> > Brain Research Institute, Melbourne, Australia
>> > Tel: +61 (0)3 9496 4078
>> >
>
>
>
> --
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9496 4078
>