How does one transform .1D.roi files to atlas space? 8-)

[claytoncurtis]

I’m trying to transform a bunch of retinotopically-defined ROIs drawn on each participant’s native space surfaces to an atlas surface (eg, std.60).

I used freesurfer recon -all and @SUMA_Make_Spec_FS to create what I think are all the required files. For instance, I have all the native space files and the std.141 and std.60 files. Those volumes and surfaces open and look correct, including eye-balling the matching sulcal/gyral anatomy between the native and atlas surfaces.

I’m confused on how to take the lh/rh.1D.roi files which define the rois drawn in native space and project those to atlas space. I’ve also tried saving as .niml.roi.

I’ve tried using SurfToSurf, @auto_tlrc with various inputs and arguments to no avail. The only thing I got to somewhat work was to use ROI2dataset to change the roi file to a dset, then use SurfToSurf to create a dset in atlas space. But that’s a dset. I was hoping to just transform my surface based rois. And I’m really trying to avoid going from surface space back to volume space for any of this.

Am I missing something? Is there an easy way to do this? Thanks!

/cc

[ptaylor]

Hi, Clayton-

In the AFNI Bootcamp data set, there is a demo of doing this; downloading the Bootcamp demo is described here (and under any setup instructions):
https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/background_install/install_instructs/steps_linux_ubuntu.html#prepare-for-bootcamp

curl -O https://afni.nimh.nih.gov/pub/dist/edu/data/CD.tgz
tar xvzf CD.tgz
cd CD
tcsh s2.cp.files . ~
cd ..

Then, in the suma_demo/afni/ directory, there is a script called “run_tuna_surf2vol”: despite its name, it is generally applicable to turning a SUMA-drawn ROI → a surface dset → volumetric dset. (If you named your drawn ROI “tuna”, then it runs with no option; if by some chance you did not name the ROI “tuna”, you can provide the name of your ROI to the script; it will assume it is a “lh” ROI, just in the demo-- there is nothing special about the left-hemisphereness, it is just for a name.) In either case, the two commands in that script provide the recipe for going SUMA surface ROI → surface → volumetric dset.

–pt

[claytoncurtis]

Thanks PT for the reply. Yes, I see what you suggest and I am able to transform the roi to volumetric space. However, is there a way to do this without going to a volumetric dset? I know freesurfer has a mri_surf2surf command that does this, but I’m working with SUMA surfaces. Thanks!

/cc

[ptaylor]

Hi, Clayton-

I see. So, to be clear, when you asked:
" I’m confused on how to take the lh/rh.1D.roi files which define the rois drawn in native space and project those to atlas space. I’ve also tried saving as .niml.roi. "
… you meant an “atlas space” of a surface, not of a volume?

One thing to note: I mentioned checking out the scripts in the Bootcamp subdirectory suma_demo/afni; actually, those are a bit out of date, and as Rick reminded me, the more uptodate ones are in the same Bootcamp download, but in the subdirectory: AFNI_data6/FT_analysis/FT/SUMA/. That will help out a bit with the subsequent description/explanation here:

The std.141* and std.60* meshes created by @SUMA_Make_Spec_FS are standardized meshes; you can read more about these here:
https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/tutorials/StandardMeshes/StandardMeshes.html
and in Ziad & Rick’s paper:

Saad_SUMA_2011.pdf

In the volumetric case, we geometrically warp a dataset to line up “voxel-by-voxel” with a reference template-- the output lies on the same grid, having mushed (in a technical sense) the brain around. In the surface case, Ziad+Rick worked out an equivalent way to perform alignment on the mesh so that every given node ID should correspond to the same anatomical location across meshes; this is done by default in SUMA, as noted above.

So, if you draw your ROI on, say, your subject’s std.60lh dset, then you can convert your ROI to a *.niml.dset with the ROI2dataset command, like this (from the aforementioned “tuna.lh” Bootcamp example):

ROI2dataset -prefix $prefix.lh.niml.dset -input $prefix.lh.niml.roi

… and those node numbers should produce the equivalent ROI on any std.60lh dset. (The same is true is you drew on a std.141lh dset-- it would apply to any std.141lh dset-- and equivalently for “rh” dsets-- too; std.60 dsets are a coarser mesh than the std.141 ones.)

I did this using the data+scripts in the AFNI_data6/FT_analysis/FT/SUMA/ directory:

• first I ran run.suma.01.lh.141
• then I drew an ROI on a nicely flattened surface there (can draw on any surface, but soooo much easier on one of those balloony-flat representations)
  • I saved the ROI with the name “tuna.lh”, to be able to use another script in the directory easily; the ROI’s full name on the disk was tuna.lh.niml.roi
• then I ran run.roi2dset, which converted the tuna.lh ROI into a surface dataset “tuna.lh.niml.dset” (and also made the volumetric representation, but you said you only care about the surface stuff here)
• then I copied the surface data set tuna.lh.niml.dset (which was drawn on a std.141lh mesh) to a directory where I had a standard space MNI152 FS mesh, and loaded that file there.
  Attached is the image of the original ROI drawn in the individual subject space (upper left, SUMA window, purple surface ROI), the ROI loaded on the MNI dset mesh (upper right, SUMA window, red surface ROI), and the volumetric version of the file created by the 3dSurf2Vol command in run.roi2dset, just because it’s cool (the AFNI volumetric viewers along the bottom, purple ROI overlay because the volume is that of the individual subject).

NB: there is nothing special or particularly standard about the MNI152 dset mesh; it was just another subject’s mesh that I had available to show the ROI dset on.

–pt