The process exits with no errors and I get a gifti metric file. However, when I try to visualize it in workbench view, the color bar shows only zeros, as if the surface template is not aligned with the volume template space. Is that the case? What is the right approach, in this case? I should add that I can view functional data in T2 space over the T2 surfaces provided with the dHCP data release with no issues.
At a later stage, I also need to perform this mapping in FreeSurfer for further analysis. Unfortunately, I am as new to surfaces as to FS. Is mri_vol2surf the way to go? How should I obtain the “source registration file”? Will FS output a gifti metric file or a cifti?
I think that the space of dHCP.week40.R.sphere.surf.gii is NOT the same “template” space that the volumetric data is in. Hopefully @EmmaR can clarify?
Also, you are sampling with the sphere which, even if it were in the same space, would not overlap with the cortex within the volume.
I suggest you get the native T2w space midthickness surface for this subject, transform it to the “template” space (with wb_command -surface-apply-warpfield), and then sample the volume to this surface with wb_command -volume-to-surface-mapping.
However, in this scheme, the fMRI surface for each subject, whilst in the same space, would not have vertex correspondence so group comparisons would not be possible. To achieve vertex correspondence you would need to do a surface registration between the native surface for each subject and then surface template, and then resample the native surface vertices to the surface template vertices with wb_command -surface-resample.
@EmmaR has made scripts available to do the surface registration step here:
Volume and surface templates are sadly not in the same space no.
You can get your data onto the template by resampling the fMRI onto the meshes generated from the scripts Sean linked. These register the individuals to the template and then sample the white, pial and midthickness with correspondence to the 32K template - creating equivalent files which end in ‘32k_fs_LR.surf.gii’ (according to the current script naming system). If you use -volume-to-surface-mapping with these then they will be in correspondence with the bozek atlas.
Having said all that, there is a new symmetric template Cortical Surface Template – Brain Development with corresponding scripts which we have ready to push to the github. @sean what is the status of the third release including the surface registration files?
Thank you both very much both for your answers, they were extremely helpful!
When I try the “warped” T2w midthickness surface I get some small empty regions (especially around the occipital lobe), in what I asume are errors in the approximation performed by workbench. I will continue by registering the T2w surfaces to the surface atlas.
Sure, I am sorry for being so little specific. It is easier to show on this independent component map (z-score), but the spots of value zero near the occipital lobe and ~0 near the frontal lobe are also present in the BOLD signals.
I think it may have something to do with the volumetric atlas’ mask being more conservative, and that is why it is more noticeable on the melodic result; but I could be completely off.
It might be that there are alignment issues. Alternatively, you might not have BOLD signal at these vertices due to susceptibility distortion and/or signal loss.
You can also use wb_command -metric-dilate to dilate across the surface and fill in some of these holes.
Thank you very much for your suggestion! i was looking indeed at a subject with a noticeable signal loss around the occipital lobe, as you will see in the picture below.
I understand the BOLD images in dhcp_fmri_pipeline already went through fieldmap correction, right? I’m trying to think in strategies to mitigate this problem.
@EmmaR, thank you again for your help. I resampled the fMRI onto the meshes like you suggested and got good results. However, there is a line in the align_to_template shell script that needs files not present in the repository:
# need to concatenate msm warp to local template with warp from local template to 40 week template
${WB_BIN} -surface-sphere-project-unproject ${outname}sphere.reg.surf.gii ${refmesh} ${SURF2TEMPLATE}/dHCP_between_template_warps/${age}-to-40.MSMSulc.sphere.reg.surf.gii ${outname}sphere.reg40.surf.gii
I assumed this this step is only necessary when trying to use a template different from the 40 week atlas, is that right? I was wondering how should I generate those “dHCP_between_template_warps”, is there maybe a workbench command that will help? Thank you very much in advance!
If you are using the pre-processed data then it has already undergone fieldmap-based distortion correction. However, there is no way to recover lost signal. Unfortunately, this pattern of signal loss is not uncommon in the dHCP bold data.
When mapping to the surface, my approach is to mask out voxels affected by signal loss so that they do not contribute to the surface vertices, and then to dilate along the surface to fill any holes. Obviously, the data for the affected subjects at these vertices is not real, but it allows them to be incorporated into group analysis with subjects that do have meaningful data at these vertices. I can resolve very nice occipital group surface ICA RSNs with this approach.
The mask is a volumetric mask with 1’s for good voxels to be included and 0’s for voxels to be excluded. This can be created in a number of ways. The (adult) HCP exclude noisy voxels over time (see lines 94-116 of RibbonVolumeToSurfaceMapping.sh in the HCP pipelines). Alternatively you could try intensity thresholding to exclude low intensity voxels where there is likely signal loss. You can include the mask in your wb_command -volume-to-surface-mapping call with the argument -volume-roi.
I’ll leave it to @EmmaR and/or @lzjwilliams to comment on the surface registration, however I can advise that we are in the final stages of prepping release 3 and expect to release it within the next week or two. This will have surface registration files as part of the release.
There are two versions of the ‘align_to_template’ code - one for the second release and one for the third release. By the look of the code snippet you pasted, that script is for the second release. There are two things you could do:
Comment out this line of code so that it doesn’t look for these files. You will need to make sure that {outname}sphere.reg.surf.gii is renamed to {outname}sphere.reg40.surf.gii so that the rest of the script will work. The downside with this is that there is registration from native directly to the 40 week template, which is not ideal.
Use the surface template for the third release, which is available at the URL @EmmaR posted prior. There is now an ‘align_to_template_3rd_release.sh’ script on @EmmaR’s GitHub which does a native-to-local registration and then concatenates warps to bring it into 40 week space. I only just realised that the files required for the warp concatenation aren’t included in the surface atlas so I have emailed the website host to update it. The downside of using the third release script is that it uses file naming that is compatible with the third release, so will require renaming of files to work.
@diegoder, I have just updated the align_to_template.sh script (2nd release) on GitHub so that it will run without the local-to-template warp concatenation. Please let me know if you still have trouble
Thanks @lzjwilliams and @EmmaR for providing the atlases, scripts and warps. I am working with the new atlas (the symmetric) and the script of the 3rd release. I have a follow up question: what config file is more suitable for this code/atlas? the one here or the ones that @lzjwilliams provided me in the FSL forum? and what are the differences between the standard file, the relaxed affine, and the pre-rotation? Thanks in advance.
The one on the FSL mailing list is the one that should be used with the new symmetric atlas. The lambda values are lower in the latest config file, which mean that there is less regularisation in the registration, allowing for better alignment in the frontal lobes. I have updated the GitHub for the dHCP_template_alignment so that it includes the updated config file called “config_subject_to_40_week_template_3rd_release.” I will let @EmmaR comment on the what the other config files might be used for.
The week-to-40 warp concatenation files that the 3rd release dHCP_template_alignment script calls for are now included in the .zip file on the Brain Development website here: Cortical Surface Template – Brain Development
@mblesac, you will also need these files in order to run registration to the new symmetric template
Thank you very much for all the help and the modified scripts. I am unsure about something:
If my desired output is the 40 week atlas, shouldn’t I avoid concatenating any further warps?
Lastly, I am not sure if that is the intended use, but I just wanted to let you know that align_to_template.sh uses what I asume is the 1st release file structure, not the 2nd (namely, there is no Native folder and “hemi” is ommited). You can disregard this comment if that is how it is supposed to be.
Probably @EmmaR and @lzjwilliams can explain better about this, but the idea of behind the warps concatenation is:
This population has a lot of variability and they grow so fast, so it is a good practice to register each subject to his own age-appropriate template, for example, a subject of 44 weeks to the 44 weeks template. Then you have the registrations between templates and you concatenate the subject → 44 weeks template with the 44 weeks template → 40 weeks template, this will give you your subject in the 40 weeks template space.
@mblesac is right When we are registering neonatal cortical surfaces from their native space to the template, we are driving alignment using their sulcal depth maps. In the case of a baby scanned at 28 week’s PMA for example, their sulcal depth maps are very simple, only really having the central sulcus and the lateral fissure. Then compare this to a baby scanned at 44 weeks’ PMA, where their cortical folding is far more complex. If we register the 28 week baby to the 40 week template, many of the sulcal landmarks aren’t present in the 28 week baby. In order to mitigate this effect, we take an iterative approach where each week is registered to the week above e.g. 28 weeks → 29 weeks, and 29 weeks → 30 weeks. From this, you can ‘concatenate’ the registration warps between these weeks to ultimately get from, say 28 weeks’ PMA, to 40 weeks’ PMA.
Thank you so much! It makes a lot of sense and I was overlooking this fact. I am curious to know if those registration warps between weeks are available for the second release of the atlas, they were not in the download file.
