I am having a little bit of trouble with running a simple group analysis using surface data. I used 3dVol2Surf to map the volume data to the std 141 surface and 2 of my participants do not have the expected number of vertices (198812). I am attaching a screenshot of the 3dinfo if it is of any help.
Hmm, that is a weird number of nodes to have—198,259 instead of 198,812. Fascinating.
This would list out the number of *niml.dset files in the current directory in time reversed order, showing the number of dimensions each dset has:
3dinfo -n4 -prefix `\ls -tr *niml.dset`
Perhaps you could see which dset that should have 198,812 has the wrong number, as a start.
Is this script something that is based on an afni_proc.py command, but not actually made by afni_proc.py? It might help to have a copy of the text itself, rather than a screenshot, so the text is searchable. I can probably compare it more easily with an afni_proc.py command script, then, to see if something jumps out.
Given that the number of nodes is close-but-not-quite, I wonder if there were a few “out of bounds” values in one of the input dsets, and that this 3dVol2Surf option wasn’t used:
-oob_value VALUE : specify default value for oob nodes
e.g. -oob_value -999.0
default: -oob_value 0.0
See -oob_index, above.
VALUE will be output for nodes which are out of bounds.
… and if those out-of-bound values would have been re-coded in the dset with this option being used, but were just dropped since it wasn’t included? The afni_proc.py script version of surface-based processing does include this option:
First off thank you for your help and quick response. I added the -oob_value flag and it worked!
Just a little context to answer your questions, although it is not all that interesting/relevant to anybody except me lol. The script I used wasn’t from proc.py. This is a relatively old data set with 2 days of scanning, day 1 was analyzed in surface but day 2 wasn’t. So I applied the part of the day 1 script related to the surface transformation to the day 2 data and it didn’t include the oob flag.
OK, glad that sorted things.
I will just note that if you are processing FMRI analysis with using surface projection, then afni_proc.py can help with a lot of the details: