<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> The tensor is stored in lower triangular order, i.e., Dxx, Dyx, Dyy,<br>
Dzx, Dzy, and Dzz. I concated the images in xx, yy, zz, yx,zx, zy<br>
order, but now the image is flipped L-R, S-I, and A-P. Does mrconvert<br>
has the options for inverting axis directions, i.e. yx to xy, zx to<br>
xz, and zy to yz?<br></blockquote><div><br></div><div>try: mrconvert in.nii -coord 0 X:0 -coord 1 Y:0 -coord 2 Z:0 out.nii</div><div>where X, Y, and Z are the respective dimensions minus one. i.e. 127 for a 128 image.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Also, "csdeconv", and "streamtrack" need the DWI but not DTI for the<br>
input. How can I perform tractography using the tensor images?<br></blockquote><div><br></div><div>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.</div>
<div> </div><div>Cheers,</div><div><br></div><div>Donald.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">
<br>
<br>
> Hi Ping,<br>
> It should be able to, but the order of the tensor elements would need to be<br>
> changed. MRtrix assumes they are stored as xx, yy, zz, xy, xz, yx. You<br>
> should be able to do this by using the -coord option of mrconvert, i.e.<br>
> mrconvert original.nii -coord 3 0,3,5,1,2,4 final.nii, which means: for the<br>
> 4th dimension (axis 3 starting from 0), take volumes 1,4,6,2,3,5 in that<br>
> order. I think that order should work, you'll need to check that.<br>
> There might be an issue if your 4D dataset is actually 5D, with the 4th axis<br>
> having dimension 1. I think this is actually what the NIfTI standard states<br>
> for storing the tensor elements. If that's the case, things get a bit<br>
> tricky, but this might work:<br>
> $ mrconvert original.nii -coord 4 0,3,5,1,2,4 temp-[].mif<br>
> $ mrcat temp-*.mif -axis 3 final.nii<br>
> Cheers,<br>
><br>
> Donald.<br>
><br>
> On 12 February 2011 07:53, Ping-Hong Yeh <<a href="mailto:pinghongyeh@gmail.com">pinghongyeh@gmail.com</a>> wrote:<br>
>><br>
>> Hi Donald,<br>
>><br>
>> Can Mrtrix import a 4-D warped tensor file, ie. in xx, xy, xz ....in<br>
>> NIFTI format for processing? Thanks.<br>
>><br>
>> Ping<br>
>><br>
>> On Mon, Jan 17, 2011 at 2:35 AM, Donald Tournier<br>
>> <<a href="mailto:d.tournier@brain.org.au">d.tournier@brain.org.au</a>> wrote:<br>
>> > Hi Ping,<br>
>> > OK, since you supply your own gradient encoding, you need to be able to<br>
>> > supply it with respect to scanner coordinates. In other words, if the<br>
>> > data<br>
>> > were not acquired in a straight axial plane, that rotation needs to be<br>
>> > accounted for. I guess there are two options: you can either discard the<br>
>> > transform altogether (for example by using the ANALYSE format), or<br>
>> > modify<br>
>> > your encoding according to the rotation part of the image transform (the<br>
>> > top<br>
>> > left 3x3 part of the transformation matrix). I'm guessing it's easiest<br>
>> > for<br>
>> > you to simply use ANALYSE, unless you actually need to keep the images<br>
>> > in<br>
>> > scanner coordinates.<br>
>> > Otherwise, I'll add a note to my (lengthy) TODO list to add an extra<br>
>> > option<br>
>> > to specify that the DW directions are defined with respect to the image<br>
>> > axes, which should help sort out this type of issue. I don't expect<br>
>> > that'll<br>
>> > happen for some time though...<br>
>> > Cheers,<br>
>> > Donald.<br>
>> ><br>
>> > On 16 January 2011 01:58, Ping-Hong Yeh <<a href="mailto:pinghongyeh@gmail.com">pinghongyeh@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi Donald,<br>
>> >><br>
>> >> Our DICOM header has wrong gradient table because we added several b0<br>
>> >> images inbetween but the sequence output the original diffusion<br>
>> >> gradient directions used by the GE vendor. For this reason, I need to<br>
>> >> use the "-grad" flag for specifying correct gradient table in the<br>
>> >> commands.<br>
>> >><br>
>> >><br>
>> >> Here is waht I did,<br>
>> >><br>
>> >> mrconvert J:\Data\DTI\DICOM\NCNC0017 dwi.mif<br>
>> >> dwi2tensor dwi.mif -grad J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt<br>
>> >> dt_mrtrix_orig.mif<br>
>> >> tensor2FA dt_mrtrix_orig.mif fa_mrtrix_orig.mif<br>
>> >> tensor2FA dt_mrtrix_orig.mif - | mrmult - b0mask.nii<br>
>> >> fa_mrtrix_brain_orig.mif<br>
>> >> tensor2vector dt_mrtrix_orig.mif - | mrmult - fa_mrtrix_orig.mif<br>
>> >> ev_orig.mif<br>
>> >> erode b0mask.nii - | erode - - | mrmult fa_mrtrix_orig.mif - - |<br>
>> >> threshold - -abs 0.6 sf_orig.mif<br>
>> >> estimate_response dwi.mif sf_orig.mif -lmax 6 -grad<br>
>> >> J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt response_lmax6_orig.txt<br>
>> >> -info<br>
>> >> csdeconv dwi.mif response_lmax6_orig.txt -lmax 6 -mask b0mask.nii<br>
>> >> -grad J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt CSD6_orig.mif<br>
>> >> gen_WM_mask dwi.mif -grad J:\Data\DTI\bvecs_mrtrix_55_orig_bvec.txt<br>
>> >> b0mask.nii wm_orig.mif<br>
>> >> threshold wm_orig.mif -percent 0.01 wm_mask_orig.nii<br>
>> >> streamtrack SD_PROB CSD6_orig.mif -seed wm_orig.mif -mask<br>
>> >> wm_mask_orig.nii -number 500000 wmtracks_sdprob_csd6_500000_orig.tck<br>
>> >> tracks2prob wmtracks_sdprob_csd6_500000_orig.tck -template dwi.mif<br>
>> >> -vox 0.5 -fraction wmtrack_sdprob_csd6_500000frac_vox0.5_orig.nii<br>
>> >><br>
>> >><br>
>> >> Thank you,<br>
>> >><br>
>> >> Ping<br>
>> >><br>
>> >> On Fri, Jan 14, 2011 at 8:45 PM, Donald Tournier<br>
>> >> <<a href="mailto:d.tournier@brain.org.au">d.tournier@brain.org.au</a>> wrote:<br>
>> >> > Hi Ping,<br>
>> >> > Sounds strange. Not sure I can really help without more detailed<br>
>> >> > information. Could you send me the transcript of the commands that<br>
>> >> > you<br>
>> >> > typed, from start to finish? Maybe I can spot where things may have<br>
>> >> > gone<br>
>> >> > funny...<br>
>> >> > Cheers,<br>
>> >> > Donald.<br>
>> >> ><br>
>> >> > On 15 January 2011 03:27, Ping-Hong Yeh <<a href="mailto:pinghongyeh@gmail.com">pinghongyeh@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> 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<br>
>> >> >> 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<br>
>> >> >> 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>
>> >> >> <<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<br>
>> >> >> > store<br>
>> >> >> > the<br>
>> >> >> > transformation matrix (i.e. the directions of the axes and<br>
>> >> >> > location<br>
>> >> >> > of<br>
>> >> >> > the<br>
>> >> >> > origin with respect to real/scanner space), whereas NIfTI does.<br>
>> >> >> > This<br>
>> >> >> > is<br>
>> >> >> > one<br>
>> >> >> > of the reasons I urge everyone to stay well away from ANALYZE<br>
>> >> >> > format<br>
>> >> >> > images<br>
>> >> >> > (the other being that left/right ordering is ill-defined).<br>
>> >> >> > If you convert a NIfTI image with a proper transformation matrix<br>
>> >> >> > to<br>
>> >> >> > ANALYZE,<br>
>> >> >> > that information is lost. I guess the overlay function in FSLView<br>
>> >> >> > operates<br>
>> >> >> > on a voxel-by-voxel basis - i.e. that the transformation<br>
>> >> >> > information<br>
>> >> >> > is<br>
>> >> >> > ignored, and only voxel coordinates within the imaging volume are<br>
>> >> >> > taken<br>
>> >> >> > into<br>
>> >> >> > account. This is not the case for MRtrix: each voxel is displayed<br>
>> >> >> > in<br>
>> >> >> > the<br>
>> >> >> > correct location, according both to its voxel coordinate within<br>
>> >> >> > the<br>
>> >> >> > imaging<br>
>> >> >> > volume, and the transformation information. Note that with ANALYZE<br>
>> >> >> > images,<br>
>> >> >> > MRtrix will insert a default identity transform (no rotation,<br>
>> >> >> > origin<br>
>> >> >> > in<br>
>> >> >> > the<br>
>> >> >> > middle of the dataset). That should explain the mismatch in the<br>
>> >> >> > overlay.<br>
>> >> >> > If<br>
>> >> >> > you want to double-check this, use 'mrinfo' on both images, and<br>
>> >> >> > see<br>
>> >> >> > if<br>
>> >> >> > the<br>
>> >> >> > transforms differ.<br>
>> >> >> > On the other hand, I have no idea why the TDI maps are so<br>
>> >> >> > different.<br>
>> >> >> > I'm<br>
>> >> >> > assuming you have to supply your own gradient encoding, and that<br>
>> >> >> > you're<br>
>> >> >> > using the same encoding file in both cases? Other than strange<br>
>> >> >> > effects<br>
>> >> >> > due<br>
>> >> >> > to different gradient encodings, I have no idea what the issue<br>
>> >> >> > might<br>
>> >> >> > be.<br>
>> >> >> > One<br>
>> >> >> > possibility is that you're using a gradient table suitable for<br>
>> >> >> > analysis<br>
>> >> >> > using FSL, where the gradient directions are supplied with respect<br>
>> >> >> > to<br>
>> >> >> > the<br>
>> >> >> > image axes. Since MRtrix assumes that they are supplied with<br>
>> >> >> > respect<br>
>> >> >> > to<br>
>> >> >> > real/scanner space, if there is a significant rotation component<br>
>> >> >> > in<br>
>> >> >> > the<br>
>> >> >> > transformation, the tracking will be affected. Might explain why<br>
>> >> >> > the<br>
>> >> >> > tracking is OK with ANALYZE (the transform has been discarded - no<br>
>> >> >> > rotation)<br>
>> >> >> > but not with NIfTI. Although there doesn't seem to be a huge<br>
>> >> >> > rotation<br>
>> >> >> > between them judging from your screenshot...<br>
>> >> >> > On a final note, if you have access to the DICOM data, why not use<br>
>> >> >> > MRtrix to<br>
>> >> >> > do the conversion for you? If you convert to MRtrix image format<br>
>> >> >> > (.mif),<br>
>> >> >> > you<br>
>> >> >> > will have the correct transform information, the DW gradient table<br>
>> >> >> > will<br>
>> >> >> > be<br>
>> >> >> > inserted in the header, and you shouldn't have any problems of<br>
>> >> >> > this<br>
>> >> >> > 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>><br>
>> >> >> > 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<br>
>> >> >> >> NIFTI<br>
>> >> >> >> was converted from DICOM originally using dcm2nii and then to<br>
>> >> >> >> ANALYZE<br>
>> >> >> >> using FSL fslchfiletype. Both images are aligned well while<br>
>> >> >> >> viewing<br>
>> >> >> >> using FSLview (see attached Screenshot_fslview.png); but there<br>
>> >> >> >> 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<br>
>> >> >> >> images,<br>
>> >> >> >> 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<br>
>> >> >> >> 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<br>
>> >> >> >> > apply<br>
>> >> >> >> > a<br>
>> >> >> >> > 4x4<br>
>> >> >> >> > affine transform: it's designed to apply a non-linear warp to<br>
>> >> >> >> > the<br>
>> >> >> >> > track<br>
>> >> >> >> > data. The warp information should be supplied as a 4D image,<br>
>> >> >> >> > where<br>
>> >> >> >> > the<br>
>> >> >> >> > values for each voxel are set to the coordinates that this<br>
>> >> >> >> > voxel<br>
>> >> >> >> > maps<br>
>> >> >> >> > to. To<br>
>> >> >> >> > help generate the warp, there is a utility called<br>
>> >> >> >> > 'gen_unit_warp',<br>
>> >> >> >> > which<br>
>> >> >> >> > will generate a 'no warp' image (i.e. each voxel contains its<br>
>> >> >> >> > own<br>
>> >> >> >> > location),<br>
>> >> >> >> > to which you can apply the relevant inverse warp using whatever<br>
>> >> >> >> > software<br>
>> >> >> >> > package you use for your normalisation (FSL, SPM, etc). You can<br>
>> >> >> >> > 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<br>
>> >> >> >> > using<br>
>> >> >> >> > SPM8,<br>
>> >> >> >> > using the warp computed by normalising a T1 image (anat.nii)<br>
>> >> >> >> > previously<br>
>> >> >> >> > coregistered with the FA:<br>
>> >> >> >> > Assuming you are normlising to the default T1<br>
>> >> >> >> > template image (T1.nii)<br>
>> >> >> >> > supplied with SPM8, start by generating a unit warp image using<br>
>> >> >> >> > that<br>
>> >> >> >> > 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<br>
>> >> >> >> > NIfTI,<br>
>> >> >> >> > 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,<br>
>> >> >> >> > select<br>
>> >> >> >> > SPM->Spatial->Normalise->Estimate in the batch editor, specify<br>
>> >> >> >> > the<br>
>> >> >> >> > anat.nii<br>
>> >> >> >> > as the source image, and T1.nii as the template, and run. This<br>
>> >> >> >> > 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:<br>
>> >> >> >> > inverse"<br>
>> >> >> >> > 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<br>
>> >> >> >> > 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<br>
>> >> >> >> > used<br>
>> >> >> >> > directly in<br>
>> >> >> >> > "normalise_tracks":<br>
>> >> >> >> > $ normalise_tracks tracks.tck wwarp-[].nii<br>
>> >> >> >> > 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>><br>
>> >> >> >> > wrote:<br>
>> >> >> >> >><br>
>> >> >> >> >> Hello all,<br>
>> >> >> >> >><br>
>> >> >> >> >> I would like to transforming the tracks to the template<br>
>> >> >> >> >> space,<br>
>> >> >> >> >> but<br>
>> >> >> >> >> not sure how to apply the transformation matrix (4 by4 Ascii)<br>
>> >> >> >> >> 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>
>> >> ><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>
><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>