[Mrtrix-discussion] transform and normalise tracks

Sun Feb 13 17:09:18 PST 2011

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