 |
 |
Hi Thomas, You are really delving into the inner workings of FSL now. Is there a particular reason for this? We have tried to provide higher-level tools for people to conveniently work with rather than have to explain the more complicated (and not as consistent) inner workings. The reason that the translations are different is because the centre of rotation is chosen differently inside mcflirt compared to flirt, but the matrices that are output are in flirt conventions (where the centre of rotation is the 0,0,0 coordinate). A different centre of rotation is used to get the parameters because it tends to reduce the coupling between the rotation and the translation parameters. Is this helpful? Is this enough? Maybe explain why you want to know this, as there may be a much better way of achieving your goal with tools that we already provide, rather than explaining all the nitty-gritty of how the code works. All the best, Mark On 30 Nov 2011, at 07:11, Thomas Yeo wrote: > Hi Mark, > > thank you! However, I think I am still missing something. In my case, > the translation parameters in .par file does not seem to match that of > the output matrix. See output below: > >>> mcflirt -in input.nii.gz -out input_mc.nii.gz -mats -plots -refvol 0 -rmsrel -rmsabs -report >>> head -n 2 input_mc.nii.gz.par > 0 -0 0 0 0 0 > 0 -5.36371e-05 0 -2.51772e-05 0.0353457 -0.0244103 >>> avscale --allparams input_mc.nii.gz.mat/MAT_0001 > Rotation & Translation Matrix: > 1.000000 0.000000 0.000054 -0.003990 > 0.000000 1.000000 0.000000 0.035346 > -0.000054 0.000000 1.000000 -0.018570 > 0.000000 0.000000 0.000000 1.000000 > > Rotation Angles (x,y,z) [rads] = 0.000000 -0.000054 0.000000 > > Translations (x,y,z) [mm] = -0.003990 0.035346 -0.018570 > > Thanks, > Thomas > > > > > On Tue, Nov 29, 2011 at 5:23 PM, Mark Jenkinson <[log in to unmask]> wrote: >> Hi Thomas, >> >> The rotation matrix is formed as such: >> R = Rx.Ry.Rz >> and the translations are put in the 4th column. >> This matrix multiplies the input coordinates >> to form transformed coordinates in the reference >> space. >> >> Given the amount of confusion about "radiological" >> and "neurological" ordering, I'm not touching >> "clockwise" with a barge-pole. You can take any >> flirt or mcflirt matrix and get the equivalent >> decomposition into parameters using: >> avscale --allparams >> >> This way you can find yourself a "clockwise" >> one (according to your definitions of this term) >> and see what the angles are like! >> >> All the best, >> Mark >> >> >> On 29 Nov 2011, at 04:49, Thomas Yeo wrote: >> >>> Dear Mark (or other FSL experts), >>> >>> to clarify and expand on this question about in 2009 about the .par >>> output of mcflirt, can I confirm that >>> >>> 1) rot_x is applied first, followed by rot_y, followed by rot_z, >>> followed by the displacement (trans_x, trans_y, trans_z)? >>> >>> 2) And that the rot_x is rotation about x axis in the clockwise >>> direction, etc. as suggested by Satra? >>> >>> Thanks, >>> Thomas >>> >>> >>> >>> >>> >>> Hi, >>> >>> Not quite - they are the parameters you need to align with >>> the reference volume (the middle of the timeseries in FSL). >>> >>> All the best, >>> Mark >>> >>> >>> On 9 Feb 2009, at 01:09, Satrajit Ghosh wrote: >>> >>>> Hi, >>>> >>>> Thanks. So am I correct in assuming the following: >>>> >>>> rot_x, rot_y, rot_z, trans_x, trans_y, trans_z >>>> >>>> rotations in radians and clockwise >>>> translations in mm >>>> >>>> These are scan to scan changes rather than cumulative (like SPM). >>>> >>>> Cheers, >>>> >>>> Satra >>>> >>>> >>>> On Sun, Feb 8, 2009 at 1:57 PM, Xinian Zuo <[log in to unmask]> >>>> wrote: >>>>> the first three columns are rot and last three are trans. >>>>> >>>> >>> Hi, >>> >>> Is there a specification somewhere for the motion parameter estimates >>> (par file) of mcflirt? I'm looking for information such as which >>> fields are rotation, translation, what are the dimensions, is it scan >>> to scan motion or cumulative, etc. >>> >>> Thanks, >>> >>> Satra >>> >