[Mrtrix-discussion] transform and normalise tracks

Sun Feb 13 19:16:16 PST 2011

Hi Donald,

 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?

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

Ping

> 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
>