Hi Rick,

thanks for your quick reply; please see below:

rick reynolds wrote:

> In any case, I had assumed that obliquity was the problem, but
> am
> less sure now.

Any ideas about other factors that may cause the problem?

> After step 1, is anat_al+orig still oblique? What does 3dinfo
> say?

Yes, it is still oblique:
Geometry String: "MATRIX(0.049084,-0.011101,-0.998733,81.35017,0.993329,0.105009,0.047651,-183.0944,0.104347,-0.994409,0.016181,141.5323):288,288,175"
Data Axes Tilt: Oblique (6.622 deg. from plumb)

FYI, also the anat_al_nob2s+orig (the attempt to get rid of the 3dAllineate headers) is oblique:
Geometry String: "MATRIX(0.02531,0.084238,-0.988029,65.1333,1.00208,0.110271,0.03139,-179.603,0.125987,-0.97666,-0.065885,161.25):288,288,175"
Data Axes Tilt: Oblique (8.087 deg. from plumb)

> For step 3, does that mean you did not run
> @SUMA_AlignToExperiment?

Yes, that is correct. I would like to read the data from the (oblique) EPIs in matlab using the surface coordinates and not do any interpolation (besides motion correction).

> You might want to check what the SUMA manual says. I do not
> think
> that Ziad ever suggests modifying the actual surface datasets
> (.asc).

Modification of surface datasets (apply an affine transformation to the node coordinates) is supported by the ConvertSurface program... And how else could I get the surface in the same frame of reference as the original EPIs without interpolation?

> See
> [afni.nimh.nih.gov]
> for
> details. It covers @SUMA_AlignToExperiment starting on page
> 41.

Thanks, I *spelled* the fine manual already.

cheers,
Nick