I would like to upsample suma surface meshes (so that each of them comprises more vertices and faces) to potentially achieve better accuracy when projecting back and forth between volumetric and surface representations.
SurfMesh seems to the function for this purpose. However, each execution of the following command
SurfMesh -edges 2 -i_fs lh.smoothwm.asc -o_fs hd.lh.smoothwm.asc
gives me a new mesh with doubled vertices (as expected) but differently randomized vertex-index. So that the resulting high resolution smoothwm mesh won’t paired easily with an similarly generated high resolution pial mesh.
Is there a way to work around this slightly confusing behavior? Or what is the right way to upsample a surface mesh (while keeping the node-index in a meaningful or at least constant way)?
Consider using MapIcosahedron with a higher number for the ld option. The same program is used in the @SUMA_Make_Spec_FS script. Even easier is to just rerun the @SUMA_Make_Spec_FS script with the -ld option to get the finer mesh generated then. Also see the the new @surf_to_vol_spackle script for mapping back into the volume.
I’ve tried MapIcosahedron via @SUMA_Make_Spec_FS approach, but it only affects the std.ld.* surfaces (i.e., standard meshes), but not the native meshes (i.e., ?h.*.asc). This is understandable since the -ld parameter is used during the creation of the new icosahedron mesh which is mapped to the sphere.reg mesh.
Is it possible to upsample the native meshes (e.g., by mapping the new icosahedron to the sphere rather than sphere.reg)?
As a side question, is it OK to just use the standard mesh in terms of geometric accuracy when doing the projection between surface and volume? I understand that the standard meshes largely preserve the geometric information of the cortex in the subject’s native space, and standardize different subjects by permuting the node indices only. But when looking at a standard mesh and a native mesh side by side in suma, I can still see some small differences in surface shape. So in order to achieve the highest precision possible, is it still better to use the (upsampled) native mesh? If not, why it is used as default in suma?
Thank you for mentioning (and perhaps creating) the new @surf_to_vol_spackle script, I’ll try that.
The registered sphere is the mechanism that all this registration relys on, so everything hinges on that, and the high resolution standard mesh based surfaces (ld 141) are what we recommend for analysis across subjects. There had been a bug in the NIFTI/GIFTI processing last year with @SUMA_Make_Spec_FS and MapIcosahedron that would shift the surfaces slightly, but it should be good with recent versions and with the .asc surfaces. Maybe you can send an example of what you’re seeing that’s odd.
Difference between native mesh and standard mesh
I open the meshes with the following commands, and press Z for the same number of times to arrive at presumably the same view point:
suma -i lh.smoothwm.asc &
suma -i std.200.lh.smoothwm.asc &
As shown in the attached picture, the difference are mainly two-fold:
First, there seems to be a small global shift in the std mesh (leftward and downward). Is this a real shift in the vertices coordinates, or just a visualization issue?
Second, there are small differences in the shape of small surface spikes and the shade of surface dents (highlighted in the black circles). I guess these are acceptable resampling error and should not be worried about. Am I correct?
If the above are not to be worried, is there any reason or circumstance that argues in favor of using native mesh compared with standard mesh? Assuming that one is just interested in doing single subject level analysis.
As per afni version “Precompiled binary macosx_10.7_local: Apr 30 2018 (Version AFNI_18.1.09)”, there seems to be a minor bug in @surf_to_vol_spackle which prevents it from executing. In line 205,
set surfB_arg = “-surfB $surfB”
perhaps should be
set surfB_arg = “-surf_B $surfB”
What should I use for -maskset option?
It seems that the -maskset is also used as -sv, so does it need to have the same xform embedded in its .HEAD as SurfVol_Alnd_Exp+orig.HEAD?
Also, should it be a mask that only has 1’s in the gray matter, and 0’s elsewhere? How to construct such a mask in the first place before using 3dSurf2Vol?
Thanks for your patience for reading through so many questions:P
This looks like a pretty small difference to me. The nodes are in slightly different locations, and I don’t think it’s surprising to see the small shifts. It may be better to look at the surfaces as they are in the volume by having suma talk to afni and see where the surface lands. You can use the Control Surfaces menu to show the node locations too.
I’m not sure what you’re doing exactly with the surfaces for single surface analysis, so I’ll withhold judgment.
The surfB problem was indeed a bug, and I’ve corrected it now. Thanks for letting me know.
The maskset is the dataset that you want to fill with the values from the surface dataset (…niml.dset). The spackling procedure tries to fill that volume. The -maskset is assumed to be the same as the -sv surface volume, but if you do have an aligned surface volume with a transformation in the header, it can be awkward to copy that header attribute to the maskset, so I’ve added a new -sv option to allow the aligned to experiment volume and to be more like the other SUMA programs. Thanks for the suggestion!
In such case should I use native or std.141 mesh?
Drawing fMRI defined ROIs on surface, then transform these ROIs to volume as seed/target for DTI/fiber tracking. In this case, all analyses are done at single subject level, and the ROIs need to be as precise as possible. Is native mesh a better choice for this?
I did a test by draw ROI on each surface covering the same atlas region( based on aparc.a2009s.annot.niml.dset and std.141.aparc.a2009s.annot.niml.dset respectively ), then transformed through roi2dset and surf2vol, and here is the volume ROI masks, why the mask derived from the standard surface on the right looks even better(with less holes and cover the same region as that from native surface on the left)? I also tested transform surface dset to volume by @surf_to_vol_spackle, but it looks be filled too much.
Are these understandings correct?
[ul]
[li] Standard surface is a low resolution version of native surface, but align as good as native surface to the volume(same geometry) and keeps very similar gyri and sulci(same topology);
[/li][li] The reason that standard surface can be used for group analysis is that the same number of nodes among different subjects, and the icosahedron coordinates are warped to match template(nodes in same gyrus/sulcus has similar coordinates on icosahedron);
[/li][li] When doing surface based fMRI analysis, because of their identical geometry and topology, no matter which surface is chosen, the results(activation strength and location) are same, thus the ROIs drawn based on that are same, and when ROIs transform back to volume are still same.
[/li][/ul]
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.
