Hi Ping,<div><br></div><div>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...</div>
<div>Cheers,</div><div><br></div><div>Donald.</div><div><br></div><div><br><div class="gmail_quote">On 15 January 2011 03:27, Ping-Hong Yeh <span dir="ltr"><<a href="mailto:pinghongyeh@gmail.com">pinghongyeh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Donald,<br>
<br>
Thank you again for the reply.<br>
<br>
The reason using the NIFTI instead of DICOM is because we would like<br>
to correct EPI distortion using fieldmap beforehand.<br>
<br>
Anyhow, I also input the DICOM files using mrconvert and the result of<br>
TDI image is similar to the one using NIFTI as the input. I still<br>
think the TDI using ANLYZE one looks right, but do not understand why<br>
there is such a huge difference.<br>
<br>
Any further comment? Thanks.<br>
<br>
Ping<br>
<br>
On Thu, Jan 13, 2011 at 2:35 AM, Donald Tournier<br>
<div><div></div><div class="h5"><<a href="mailto:d.tournier@brain.org.au">d.tournier@brain.org.au</a>> wrote:<br>
> Hi Ping,<br>
> I'm guessing your issues are due to the fact that ANALYZE does not store the<br>
> transformation matrix (i.e. the directions of the axes and location of the<br>
> origin with respect to real/scanner space), whereas NIfTI does. This is one<br>
> of the reasons I urge everyone to stay well away from ANALYZE format images<br>
> (the other being that left/right ordering is ill-defined).<br>
> If you convert a NIfTI image with a proper transformation matrix to ANALYZE,<br>
> that information is lost. I guess the overlay function in FSLView operates<br>
> on a voxel-by-voxel basis - i.e. that the transformation information is<br>
> ignored, and only voxel coordinates within the imaging volume are taken into<br>
> account. This is not the case for MRtrix: each voxel is displayed in the<br>
> correct location, according both to its voxel coordinate within the imaging<br>
> volume, and the transformation information. Note that with ANALYZE images,<br>
> MRtrix will insert a default identity transform (no rotation, origin in the<br>
> middle of the dataset). That should explain the mismatch in the overlay. If<br>
> you want to double-check this, use 'mrinfo' on both images, and see if the<br>
> transforms differ.<br>
> On the other hand, I have no idea why the TDI maps are so different. I'm<br>
> assuming you have to supply your own gradient encoding, and that you're<br>
> using the same encoding file in both cases? Other than strange effects due<br>
> to different gradient encodings, I have no idea what the issue might be. One<br>
> possibility is that you're using a gradient table suitable for analysis<br>
> using FSL, where the gradient directions are supplied with respect to the<br>
> image axes. Since MRtrix assumes that they are supplied with respect to<br>
> real/scanner space, if there is a significant rotation component in the<br>
> transformation, the tracking will be affected. Might explain why the<br>
> tracking is OK with ANALYZE (the transform has been discarded - no rotation)<br>
> but not with NIfTI. Although there doesn't seem to be a huge rotation<br>
> between them judging from your screenshot...<br>
> On a final note, if you have access to the DICOM data, why not use MRtrix to<br>
> do the conversion for you? If you convert to MRtrix image format (.mif), you<br>
> will have the correct transform information, the DW gradient table will be<br>
> inserted in the header, and you shouldn't have any problems of this kind.<br>
> Hope that sort things out for you.<br>
> Cheers,<br>
> Donald.<br>
><br>
> On 12 January 2011 15:24, Ping-Hong Yeh <<a href="mailto:pinghongyeh@gmail.com">pinghongyeh@gmail.com</a>> wrote:<br>
>><br>
>> Hi Donald,<br>
>><br>
>> Thank you for the detailed explanation.<br>
>><br>
>> Another question about the input data format.<br>
>><br>
>> First, I have the same DWI data saved as NIFTI or ANALYZE. The NIFTI<br>
>> was converted from DICOM originally using dcm2nii and then to ANALYZE<br>
>> using FSL fslchfiletype. Both images are aligned well while viewing<br>
>> using FSLview (see attached Screenshot_fslview.png); but there is a<br>
>> significant translation while viewing using mrview<br>
>> (mrview_screen.jpg).<br>
>><br>
>> I then processed both data and created the whole brain TDI images, but<br>
>> the results are quite different (see tdi_analyze.jpg and<br>
>> tdi_nifti.jpg). It appear the TDI image by using ANALYZE is what TDI<br>
>> is supposed to be looked like although now it does not align with<br>
>> original NIFTI data, which has made the previous co-registration<br>
>> matrices useless.<br>
>><br>
>><br>
>> Thank you,<br>
>><br>
>> Ping<br>
>><br>
>><br>
>> On Mon, Jan 10, 2011 at 8:14 AM, Donald Tournier<br>
>> <<a href="mailto:d.tournier@brain.org.au">d.tournier@brain.org.au</a>> wrote:<br>
>> > Hi Ping,<br>
>> > Unfortunately, the 'normalise_tracks' command can't be used to apply a<br>
>> > 4x4<br>
>> > affine transform: it's designed to apply a non-linear warp to the track<br>
>> > data. The warp information should be supplied as a 4D image, where the<br>
>> > values for each voxel are set to the coordinates that this voxel maps<br>
>> > to. To<br>
>> > help generate the warp, there is a utility called 'gen_unit_warp', which<br>
>> > will generate a 'no warp' image (i.e. each voxel contains its own<br>
>> > location),<br>
>> > to which you can apply the relevant inverse warp using whatever software<br>
>> > package you use for your normalisation (FSL, SPM, etc). You can then<br>
>> > feed<br>
>> > the result to 'normalise_tracks' as the transform image.<br>
>> > Getting the details can be quite tricky, so here is an example using<br>
>> > SPM8,<br>
>> > using the warp computed by normalising a T1 image (anat.nii) previously<br>
>> > coregistered with the FA:<br>
>> > Assuming you are normlising to the default T1 template image (T1.nii)<br>
>> > supplied with SPM8, start by generating a unit warp image using that as<br>
>> > a<br>
>> > template:<br>
>> > $ gen_unit_warp /opt/SPM8/templates/T1.nii warp-[].nii<br>
>> > Note that the output image has been specified as a multi-file NIfTI, so<br>
>> > this<br>
>> > should produce the files warp-1.nii, warp-2.nii & warp-3.nii.<br>
>> > Then estimate the warp you're interested in applying. In SPM8, select<br>
>> > SPM->Spatial->Normalise->Estimate in the batch editor, specify the<br>
>> > anat.nii<br>
>> > as the source image, and T1.nii as the template, and run. This will<br>
>> > generate<br>
>> > the warp information as a "anat_sn.mat" file.<br>
>> > Then, apply the inverse warp to your warp-*.nii images: select<br>
>> > SPM->Util->Deformations in the batch editor, choose "New: inverse" as<br>
>> > the<br>
>> > composition, then "New: Imported _sn.mat" as its composition,<br>
>> > "anat_sn.mat"<br>
>> > as the parameter file, and your fa.nii as the "image to base inverse<br>
>> > on".<br>
>> > Specify all 3 wrap-*.nii in the "apply to" field, and run.<br>
>> > This should generate 3 new files: wwarp-*.nii, which can be used<br>
>> > directly in<br>
>> > "normalise_tracks":<br>
>> > $ normalise_tracks tracks.tck wwarp-[].nii tracks_normalised.tck<br>
>> > Obviously the steps would be very different depending on the<br>
>> > normalisation<br>
>> > package you're using, but the idea would be the same.<br>
>> > Hope that clarifies things a little.<br>
>> > Cheers,<br>
>> > Donald.<br>
>> ><br>
>> > On 7 January 2011 15:47, Ping-Hong Yeh <<a href="mailto:pinghongyeh@gmail.com">pinghongyeh@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hello all,<br>
>> >><br>
>> >> I would like to transforming the tracks to the template space, but<br>
>> >> not sure how to apply the transformation matrix (4 by4 Ascii) using<br>
>> >> "normalise_tracks".<br>
>> >> How should the normalisation map be created? Thanks.<br>
>> >><br>
>> >> Ping<br>
>> >> _______________________________________________<br>
>> >> Mrtrix-discussion mailing list<br>
>> >> <a href="mailto:Mrtrix-discussion@www.nitrc.org">Mrtrix-discussion@www.nitrc.org</a><br>
>> >> <a href="http://www.nitrc.org/mailman/listinfo/mrtrix-discussion" target="_blank">http://www.nitrc.org/mailman/listinfo/mrtrix-discussion</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Jacques-Donald Tournier (PhD)<br>
>> > Brain Research Institute, Melbourne, Australia<br>
>> > Tel: +61 (0)3 9496 4078<br>
>> ><br>
><br>
><br>
><br>
> --<br>
> Jacques-Donald Tournier (PhD)<br>
> Brain Research Institute, Melbourne, Australia<br>
> Tel: +61 (0)3 9496 4078<br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jacques-Donald Tournier (PhD)<br>Brain Research Institute, Melbourne, Australia<br>Tel: +61 (0)3 9496 4078<br>
</div>