FreeSurfer - how to correctly project surface vertices/indices to volume space?

Hi all,

I’m trying to get surface indices from surfaces generated with recon-all into a volume in native functional/EPI space. I’m using mri_surf2vol for that, though if there is a better alternative solution, I’m happy to take it.

Currently, the issue I have is that no matter what incantation of mri_surf2vol I use, the output index volume (vtxvol) does not seem to ever be properly aligned/registered with the target space.

mri_surf2vol  --reg anat2epi.dat  --hemi lh --vtxvol vtxvol.nii.gz --fillribbon --outvol foo.nii.gz --template epi.nii.gz --mkmask

In fact, I can’t get the projection to work even if I try projecting the surface onto the anatomical space.
Here’s the incantation that I’ve been using for that:

mri_surf2vol  --hemi lh --vtxvol vtxvol.nii.gz --fillribbon --outvol foo.nii.gz --template ../mri/orig.mgz --mkmask --identity sub-01

I notice that the output vtxvol does not even have the same dimensions as the template specified in the command line, which makes me think I’m missing something.

> nib-ls vtxvol.nii.gz ../mri/orig.mgz
vtxvol.nii.gz   float32 [320, 320, 320] 1.00x1.00x1.00   sform
../mri/orig.mgz  uint8  [320, 320, 320] 0.75x0.75x0.75

I’d appreciate if anyone has any ideas on how to get mri_surf2vol to work or an alternative strategy for surface indices → volume.


Hi @dangom ,

It is hard to tell what is going wrong without seeing your data, but this sound like an interesting problem. I am guessing that there are either header issues or missing transformations between spaces (mesh coordinates to your native space). If you can provide a few files (e.g. folded mesh from freesurfer, anatomical and a volume of your EPI) I can have a look for a better insight.

Hey @ofgulban thanks for your help! I’m checking whether we can share example datasets - I think it shouldn’t be a problem.

But with that said, and looking into the source code for mri_surf2vol, it seems that the issue is that the output volume is saved in CRS space, not in RAS.
I’m not familiar with all of the FreeSurfer transforms to fully understand what’s going on, but I take it’s a coordinate system issue.

Sure, no problem if you can’t share data. Alternatively, you can DM me. If I end up looking into it or solving it, I would just share some screenshots explaining what was the problem and how to solve it. By the way, I was not thinking of using mri_surf2vol but to use python scripting to perform vertex to volume transformations as you also asked for an alternative strategy.

Now thinking a bit more, this is very strange. mri_surf2vol worked for me on several conventional freesurfer analysis cases. This error can point to header/data ordering issues. E.g. if some unconventional data array transpose was done on earlier stages on the anatomical file, this can break the link between the meaningful data coordinates and the interpreted data coordinates, resulting in a logical error when converting coordinates across spaces.

Wow I hope that’s not the case. I don’t do any processing on the anatomicals beyond SPM bias field correction, but on freeview the BFC corrected and the raw anatomical are always in the same space. (I actually use the bfc code Renzo shared on his blog). Then I just let recon-all roll.

If you run this command you get vtxvol.nii.gz and mri/orig.mgz aligned in the same space?!

mri_surf2vol  --hemi lh --vtxvol vtxvol.nii.gz
              --fillribbon --outvol foo.nii.gz
              --template ../mri/orig.mgz --mkmask --identity $SUBJECT

This is what I get:

1 Like

I see, well at least the axes are not messed up. Looks like a translation error and might require mirroring along left-right direction. A few follow up questions:

  1. Which program are you using to visualize these two nifti files? Do they also look misaligned in fsleyes and ITKSNAP?
  2. Are both nifti files are of the same size (e.g. 256x256x256 voxels each or do they have different numbers of voxels)?

I don’t have appropriate data on my laptop right now so I cannot test the command you put.

I was using FreeView to look at the niftis. They were also misaligned in other viewers.
Your second question though brought me to the answer: they had the same number of voxels but the resolution was different (weird right?!).

After closer investigation it turned out to be a bug in mri_surf2vol.
This line had to be placed after the closing of the if/else statement, otherwise the if branch output would not have the correct header. After fixing it the problem is gone.

Thanks for the help and suggestions!!!

I’ve reported it upstream, so hopefully it’ll be fixed on FS dev soon.

1 Like

Great news! I am happy to be of help for debugging :slight_smile: .

1 Like