[Mrtrix-discussion] transform and normalise tracks

Fri Jan 14 17:45:30 PST 2011

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