Hi Tom, it is really necessary to use BRIKs these days? AFNI has supported nifti for years. While it is possible for me to track this down and fix it, it would take me a while (time I'd rather spend doing something else:). doug ps. On the other hand, since you are probably the only one using BIRKS, I can just applied the patch you sent. I can give you a binary to test. If it tests out, then I'll just check the patch in. Let me know.
On 11/19/2012 08:21 PM, Tom Holroyd (NIH/NIMH) [E] wrote: > 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 > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center gr...@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.