Hi, I have a question about keeping the labels for ROIs that I created in SUMA. After I created and saved a set of ROIs on the surface using SUMA (with NIML and All options), I used ROI2dataset and 3dSurf2Vol to convert them into volume coords. I needed to open it in Matlab using “BrikLoad” to apply the ROIs to my data matrix in Matlab. Everything looked alright except I don’t have any labels (not the integers but the word labels) that I put for each ROIs in SUMA. What should I do to keep the labels saved in the surface data and BRIK/HEAD files?
Hi, Soo Hyun-
Yeah, that is a bit tricky, I am afraid. Hopefully the following will work. I did this using the AFNI Bootcamp data as an example, and that is where some of the dset file names come from (in this directory of the downloadable Bootcamp data: “AFNI_data6/FT_analysis/FT/SUMA/”).
Open the SUMA surface (I ran the “run.suma.00.both.141” in the above Bootcamp directory), and then draw one or more ROIs, giving each a different number and label. In my case, I made three ROIs, with the following index=label combinations: 1=abc, 2=def, 3=ghi.
In the GUI, save the dset, in my case I gave it the prefix “three_rois.lh”, because I had that many ROIs drawn on the left hemisphere.
Convert ROI to surface dset. The “-input …” must be at end:
-label_dset three_rois.lh.niml.dset \
Note: I had to use “-label_dset …” instead of “-prefix …” to preserve the ROI labels in the dataset header in a labeltable, which will be used later. You can see this information in the output as follows:
3dinfo -labeltable three_rois.lh.niml.dset
… which for me produced the following output:
- Convert the surface dataset (*.niml.dset) to a volumetric one (BRIK/HEAD or NIFTI); the command I use here mostly just follows “run.roi2dset” script example in this Bootcamp directory:
-spec std.141.FT_lh.spec \
-surf_A smoothwm \
-surf_B pial \
-sv FT_SurfVol.nii \
-grid_parent FT_SurfVol.nii \
-map_func mode \
-f_steps 12 \
-sdata three_rois.lh.niml.dset \
Note: At this point, three_rois.lh.s2v.roi+orig does not have labels; this can be seen by running:
3dinfo -labeltable three_rois.lh.s2v.roi+orig
… which just produces the message:
…so we need to attach the labeltable from the earlier-made file.
- Attach the labeltable from earlier dset that has it:
3drefit -copytables three_rois.lh.niml.dset three_rois.lh.s2v.roi+orig.
… and you can verify either in the AFNI GUI or using “3dinfo -labeltable …” again that the three_rois.lh.s2v.roi+orig.* dset has its labels now.
Thanks for the prompt reply with detailed help! It worked well and I could have labels on.
I have one more question regarding ROIs generated from SUMA. Is there any way to modify the volumetric dataset of surface-generated ROIs in AFNI? In other words, in your above example with three_rois.lh.s2v.roi+orig, whether you can open three_rois.lh.s2v.roi+orig.BRIK in the AFNI and modify each ROIs using AFNI’s ROI GUI. In my ROIs I see some errors in the boundaries of ROIs in 3d volume, probably due to the registration between my surface and 3D volume file, that I want to correct in 3D volume space. I was wondering whether there’s a way to change each ROI in AFNI somehow, but so far it seems that the 3d volume file converted from surface ROI file is read as another overlay, instead of modifiable “ROI” files.
Thanks in advance,
Hi Soo Hyun,
I think the Draw Dataset plugin would be used to modify volumetric ROI datasets. It is a bit clunky, but should work.
Hi Soo Hyun,
Adding on a little here with some more suggestions:
- Attaching labels to volumes. Besides copying labels from one dataset to another, you can also make new labeltables with @MakeLabelTable. The labels can be a little more complicated with centers associated with regions and available through whereami with @Atlasize. You only need a text file with index numbers and region labels.
- Surface to volume irregularities. Consider the @surf_to_vol_spackle program. The process of projecting from the surface to the volume can leave holes in the volume because the projection occurs over line segments (either between surfaces or from normal vectors). This program will iteratively fill a mask volume to patch the remaining holes.
- Boundary edges. If the problem is just edges of the regions when you are viewing the overlay grid over a different underlay grid, e.g. if the datasets have different resolutions, then that might come about from the overlay interpolation. NN (nearest neighbor) interpolation usually works well, but there might be subtle differences between grids. Try the linear interpolation instead, but that will give you interpolated ROI values on the edges.