Hi Doug,

MJ is away on some well deserved vacation, but I'll attempt an  
educated guess on this one.

> I'm not sure that explains what I'm seeing. If it were the case,  
> then the two trajectories would be different by an offset equal to  
> the dist from the center to the corner.

It is not the case that they would differ by a fixed offset. Think  
about a square being rotated around its center, and then think about  
representing that rotation as a rotation around its lower left corner  
and a translation.

The rotation parameter is obviously going to be the same for the two  
representations. The difference will be in the translations, that  
will now have to compensate for the "translation induced by rotating  
around the corner" (remember the "true" rotation in our example is  
around the center). If there is a "small" rotation (say theta=1  
degree) around the centre there will be a "small" translation  
compensating for it (~0.5FOV*sin(theta)), and if there is a "large"  
rotation there will be a large translation compensating for it.

So, in our example where all rotations are around the center, the  
"observed translations" will be a function of the rotations.

> But I'm seeing something very different (see attached gifs). It  
> almost looks like the MAT translation is a high-pass filtered  
> version of the .par.

Not knowing the exact details of how the values in the .par file is  
calculated, this will again be an educated guess.

The 6 parameter rigid body model we use to describe subject movement  
is in some ways a little bit of overkill. The head tends to be  
attached to some body, and the actual movements we observe will  
typically be rotations around the upper vertebrae. For example,  
unless you are scanning Yogis you are nor very likely to ever see a  
pure y-translation. One could argue that if we could find the "best"  
representation (e.g. where the centre coincides with the top  
vertebra) it would be a 5 (or possibly even 4) parameter problem.

For this reason you will typically notice that if you do an SVD on  
your movement parameters they are pretty well described by the first  
3-5 parameters.

Depending on your representation (center in corner vs center in  
"center") the dependencies between the different parameters will be  
different. From my reasoning above we would think that there is some  
representation where 1 or 2 parameters would be close to zero for all  
time points.

So, when you note that the MAT representation looks like a high-pass  
filtered version of the par, I suspect that what you really see is a  
version that has been partially orthogonalised  (i.e. filtered)  
w.r.t. to the rotations.

Most of the time (for example when you want to use the 6 parameters  
as covariates in your FEAT model) this does not matter. You can put  
in any rotation of the parameters and the results will be identical.

I hope this helps.

Puss J


>
> thanks
>
> doug
>
>
>
>
> Steve Smith wrote:
>
>> Hi Doug,
>>
>> Yes - I _think_ the answer is that the .mats are FLIRT matrices  
>> with  the coordinate centre in the corner of the image, whereas  
>> for more  useful graph plotting, the .par file has the  
>> transformations stored  relative to an image centre coordinate  
>> centre to make the different  parameters more interpretable and  
>> independent of each other.
>>
>> Hope this makes sense? Cheers, Steve.
>>
>>
>>
>>
>> On 6 Aug 2007, at 21:43, Doug Greve wrote:
>>
>>> When I run mcflirt via feat, it creates an mc directory under  
>>> which  is a prefiltered_func_data_mcf.mat directory which has a  
>>> bunch of  MAT_???? files with 4x4 matrices. I had thought that  
>>> this would be  the matrix equivalent of the rotations and  
>>> translations found in  the prefiltered_func_data_mcf.par file.
>>>
>>> The rotations do match, but I'm having a problem reconciling the   
>>> translations.  Eg,
>>>
>>> cat prefiltered_func_data_mcf.mat/MAT_0000
>>>
>>> 1.000000 0.000130 -0.000365 -0.030460
>>> -0.000129 1.000000 0.000970 -0.058024
>>> 0.000365 -0.000970 0.999999 -0.006929
>>> 0.000000 0.000000 0.000000 1.000000
>>>
>>> head -n 1 prefiltered_func_data_mcf.par
>>>
>>> 0.000969584  0.000364679  0.00012981  -0.0411323  -0.00362382    
>>> -0.080172
>>> I would have thought that the translations in the .par (the last  
>>> 3  cols) would be the same as the last row in the MAT file, but   
>>> (obviously) they are not. I think the values in the .par are the   
>>> correct translations, but then what are the values in the MAT  
>>> file?  Or am I just misinterpreting something?
>>>
>>> thanks!
>>>
>>> doug
>>>
>>>
>>>
>>> -- 
>>> Douglas N. Greve, Ph.D.
>>> MGH-NMR Center
>>> [log in to unmask]
>>> Phone Number: 617-724-2358 Fax: 617-726-7422
>>>
>>> In order to help us help you, please follow the steps in:
>>> surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>>
>>
>>
>> --------------------------------------------------------------------- 
>> --- ---
>> Stephen M. Smith, Professor of Biomedical Engineering
>> Associate Director,  Oxford University FMRIB Centre
>>
>> FMRIB, JR Hospital, Headington, Oxford  OX3 9DU, UK
>> +44 (0) 1865 222726  (fax 222717)
>> [log in to unmask]    http://www.fmrib.ox.ac.uk/~steve
>> --------------------------------------------------------------------- 
>> --- ---
>>
>>
>
> -- 
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> [log in to unmask]
> Phone Number: 617-724-2358 Fax: 617-726-7422
>
> In order to help us help you, please follow the steps in:
> surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>
>
> <prefiltered_func_data_mcf.par.gif>
> <mats.gif>