Retain SUMA vertex # using 3dmaskdump


I am using 3dmaskdump with a surface dataset to get a list of xyz coordinates, but I am hoping to preserve their SUMA vertex number, as I need to relate back to it afterwards. I tried using -index but ended up getting numbers in the 300,000s, while I only have 36,001 SUMA vertices. Any help would be much appreciated!

I just tried with a similar size data, and it works well

SurfMeasures -func coord_A -spec std.60.FT_lh.spec -surf_A std.60.lh.pial.gii -out coords.niml.dset

3dmaskdump coords.niml.dset

How are you specifying your dataset and mask? You may post your entire command.

Hi Daniel,

I have a surface and volumetric version of my dataset, peak_times. When I pass in

3dmaskdump -mask peak_times.nii -xyz -noijk peak_times.nii > peak_time.txt

I get the desired xyz coordinates but with volumetric indices. However, when I use the gifti,

3dmaskdump -mask peak_times.gii -xyz -noijk peak_times.gii > peak_time.txt,

I lose the xyz coordinates and only receive the SUMA vertices associated.

What would you recommend if I am looking to retain both?

1 Like

That depends on how peak_times.gii was made. You can go back and prepare the coordinates as your input file from the SurfMeasures command and use the mask from a different dataset (maybe something based on peak_times.gii).

Thank you, Daniel! I had one more question regarding the outputs of Surf2VolCoord. When I get back something like '342A 37.878136', how can I relate this RAImm coordinate back to a SUMA node of interest? I have read the help text but am not sure if redefining the data mode is what I would be looking for.

Surf2VolCoord can be used a couple different ways. If you use it with input coordinates, with either -closest_node or -closest_nodes, you get the output node followed by a surface descriptor index. That tells you which surface is closest to that coordinate. That's useful with multiple surfaces as input. The surfaces are in order of A,B,C,D,... (English alphabetical) by default, but you can specify another sequence optionally. In your case, the node that's closest to the coordinate is node number 342 on the first, probably only, surface you provided. The next number for this kind of output is a distance from the node. If you provide a coordinate that is very close to a node on the surface, that distance will be very close to zero.

Surf2VolCoord -closest_node '27.964 -73.914 47.9006' -sv FT_SurfVol.nii -i std.60.lh.pial.gii
11193A 0.999909

If you do not provide coordinates with the "closest" options, then the output will be coordinates of all nodes and the unrounded index and the usual rounded index within the specified surface volume. You can limit the output to particular nodes with grep or with the -one_node option.

Surf2VolCoord -i std.60.lh.pial.gii -sv FT_SurfVol.nii -one_node 11193
Node Index 11193: RAImm 27.964 -73.915 46.901 : 3dfind 157.0 77.9 184.9 : 3dind 157 78 185 : Val 63.000000

Both ways account for alignment transformations between the anatomical surface volume that has been registered to a reference volume with direct correspondence to a surface.

Hi Daniel,

Thank you for the explanation! Since I am using -closest_node and passing in a single input vector, I had assumed that's what it meant. However, I only passed in ~100 nodes, so it cannot be node number 342. I can only guess that means I'm doing something else incorrectly.

I followed @rickr 's suggestion here: Surf2VolCoord error - #8 by rickr

and using this restricted list of coordinates stored in '1_rh_cluster_xyz.1D', I'm running

Surf2VolCoord -i_vec 1_rh_cluster_xyz.1D 1_rh_cluster_xyz.1D -prefix 'closest' -closest_node '-21.0749 29.4453 27.8018'

As per Rick's comment about the mesh not being important, I used the same list as the mesh input. Even though I get a "valid" output from the command, the node index exceeds the input list and I get the following error:

Fatal Signal 11 (SIGSEGV) received
Bottom of Debug Stack
** AFNI version = AFNI_24.0.02 Compile date = Jan 23 2024
** [[Precompiled binary macos_13_ARM_clang: Jan 23 2024]]
** Program Death **
** If you report this crash to the AFNI message board,
** please copy the error messages EXACTLY, and give
** the command line you used to run the program, and
** any other information needed to repeat the problem.
** You may later be asked to upload data to help debug.
** Crash log is appended to file /Users/srinivasanl2/.afni.crashlog

Thank you in advance for any suggestions!

I also wanted to mention that when I run the command continuously without changing the inputs, I get different outputs.

That is a little strange. Make sure the mesh is integers, even if they should not be used for the final calculations.