[Mrtrix-discussion] transform and normalise tracks

[Ping-Hong Yeh]

Hi Donald,

Can Mrtrix import a 4-D warped tensor file, ie. in xx, xy, xz ....in
NIFTI format for processing? Thanks.

Ping

On Mon, Jan 17, 2011 at 2:35 AM, Donald Tournier
<d.tournier at brain.org.au> wrote:
> Hi Ping,
> OK, since you supply your own gradient encoding, you need to be able to
> supply it with respect to scanner coordinates. In other words, if the data
> were not acquired in a straight axial plane, that rotation needs to be
> accounted for. I guess there are two options: you can either discard the
> transform altogether (for example by using the ANALYSE format), or modify
> your encoding according to the rotation part of the image transform (the top
> left 3x3 part of the transformation matrix). I'm guessing it's easiest for
> you to simply use ANALYSE, unless you actually need to keep the images in
> scanner coordinates.
> Otherwise, I'll add a note to my (lengthy) TODO list to add an extra option
> to specify that the DW directions are defined with respect to the image
> axes, which should help sort out this type of issue. I don't expect that'll
> happen for some time though...
> Cheers,
> Donald.
>
> On 16 January 2011 01:58, Ping-Hong Yeh <pinghongyeh at gmail.com> wrote:
>>
>> 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
>> >
>
>
>
> --
> Jacques-Donald Tournier (PhD)
> Brain Research Institute, Melbourne, Australia
> Tel: +61 (0)3 9496 4078
>