[Mrtrix-discussion] transform and normalise tracks

Sun Feb 13 19:22:23 PST 2011

>
>  The tensor is stored in lower triangular order, i.e., Dxx, Dyx, Dyy,
> Dzx, Dzy, and Dzz.  I concated the images in xx, yy, zz, yx,zx, zy
> order, but now the image is flipped L-R, S-I, and A-P. Does mrconvert
> has the options for inverting axis directions, i.e. yx to xy, zx to
> xz, and zy to yz?
>

try: mrconvert in.nii -coord 0 X:0 -coord 1 Y:0 -coord 2 Z:0 out.nii
where X, Y, and Z are the respective dimensions minus one. i.e. 127 for a
128 image.

Also, "csdeconv", and "streamtrack"  need the DWI but not DTI for the
> input. How can I perform tractography using the tensor images?
>

Sorry, there's no option to do that. The tracking is done directly from the
DWI so that the interpolation can be done on the raw images.

Cheers,

Donald.

>
> > Hi Ping,
> > It should be able to, but the order of the tensor elements would need to
> be
> > changed. MRtrix assumes they are stored as xx, yy, zz, xy, xz, yx. You
> > should be able to do this by using the -coord option of mrconvert, i.e.
> > mrconvert original.nii -coord 3 0,3,5,1,2,4 final.nii, which means: for
> the
> > 4th dimension (axis 3 starting from 0), take volumes 1,4,6,2,3,5 in that
> > order. I think that order should work, you'll need to check that.
> > There might be an issue if your 4D dataset is actually 5D, with the 4th
> axis
> > having dimension 1. I think this is actually what the NIfTI standard
> states
> > for storing the tensor  elements. If that's the case, things get a bit
> > tricky, but this might work:
> > $ mrconvert original.nii -coord 4 0,3,5,1,2,4 temp-[].mif
> > $ mrcat temp-*.mif -axis 3 final.nii
> > Cheers,
> >
> > Donald.
> >
> > On 12 February 2011 07:53, Ping-Hong Yeh <pinghongyeh at gmail.com> wrote:
> >>
> >> 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
> >> >
> >
> >
> >
> > --
> > 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/20110214/8f543ebe/attachment-0001.html