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.
