If I do "3dcopy ortho+orig ortho.nii" then 3dinfo shows that the two datasets share the same coordinate system, however when I use mri_info, the results differ. For example,
3dinfo, both .BRIK and .nii: Geometry String: "MATRIX(0,0,-1,127,1,0,0,-127,0,-1,0,180):256,256,256" R-to-L extent: -128.000 [R] -to- 127.000 [L] -step- 1.000 mm [256 voxels] A-to-P extent: -127.000 [A] -to- 128.000 [P] -step- 1.000 mm [256 voxels] I-to-S extent: -75.000 {I] -to- 180.000 [S] -step- 1.000 mm [256 voxels]*
mri_info ortho+orig says: voxel to ras transform: 0.0000 0.0000 1.0000 -128.5000 -1.0000 0.0000 0.0000 127.5000 0.0000 -1.0000 0.0000 75.5000 0.0000 0.0000 0.0000 1.0000
while mri_info ortho.nii produces (this is correct): voxel to ras transform: -0.0000 -0.0000 1.0000 -127.0000 -1.0000 -0.0000 -0.0000 127.0000 0.0000 -1.0000 0.0000 180.0000 0.0000 0.0000 0.0000 1.0000
in particular, the center of the volume appears to be translated. So if you run FreeSurfer on the .nii file, the surface is shifted relative to what you get when you run FreeSurfer on the .BRIK file, even though the original input was the same. Also mri_info seems to have shifted things to half-integer coordinates, while the .nii version doesn't. I'm not really sure about the half-integer thing, but it's a separate issue.
I think the problem is a bug in utils/afni.c, where it calculates c_ras. I've attached a patch. The problem is that FreeSurfer wants ras coordinates, which are LPI coordinates in AFNI notation, and we're staring in dataset coordinates (here ASL). First the transform matrix is computed (correctly). Then c_ras is calculated using the AFNI DELTA and ORIGIN header fields. I'm really not sure what the old code was doing, the terms seem to be associated the wrong way. The new code correctly multiplies the ORIGIN times the DELTAs to get all negative numbers in dataset coordinates (that is, the origin). This is then added to the center, also in dataset coordinates, and then this is multiplied by the rest of the transform matrix, which is a vox2ras matrix, yielding c_ras that agrees with the result from the .nii file. Except for that half-integer thing, which boils down to the afni.c code doing (w-1)/2 and the .nii file code doing w/2. Perhaps the AFNI code shouldn't subtract 1 either ? {the relevant lines are also part of the patch, but I left in the (w-1)/2}
Unfortunately it seems there is no easy way to compute the correct c_ras if you started with a .BRIK, unless you have the original .BRIK. In that case 3dcopy it to a .nii file and mri_info that.
Err, I haven't actually tested the patch ... I'm fairly certain it's the .nii file results that are correct, and not the other way around. It would be nice to confirm that this happens with other datasets besides the one I tried. It's easy to check if you have an AFNI dataset sitting around.
Thanks, Tom