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.
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:
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.
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?!
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:
Which program are you using to visualize these two nifti files? Do they also look misaligned in fsleyes and ITKSNAP?
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?!).
.