[Mrtrix-discussion] transform and normalise tracks

Donald Tournier d.tournier at brain.org.au
Sun Jan 16 23:35:03 PST 2011 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20110117/73428e4a/attachment.html

More information about the Mrtrix-discussion mailing list