First of all, thank you very much for taking the time to answer my questions in such detailed fashion. Everything is much more clear but there are still a couple of issues I am thinking about:
You are right, I had totally missed that an affine transformation implies a resampling because of the change in resolution. Additionally, it is also true that -surface-apply-affine should not perform any resampling, and should use flirt in a “single stage mode” to apply the rigid transformation matrix, keeping the original resolution (vertex number), am I right? I have not been able to confirm this with workbench’s documentation.
Interpolation - select the interpolation method to be used in the final (reslice) transformation (it is not used for the estimation stage - trilinear interpolation is always used for the estimation of the transformation).
I am assuming this means that some interpolation error is already built-in the transformation matrices previously calculated, is that right? I cannot think of a way of bypassing that error, so I understand the idea is to avoid adding additional sources of error.
I am slightly confused. You linked to the augmented dHCP volumetric atlas, which is the same (same space) as the original but with the computed week-to-week warps, isn’t it? Is this the link to the extended atlas discussed above?
It is hard to know the exact implications of using the Serag et al. atlas rather than the Schuh et al. atlas - do the two 40w templates look rotated relative to one another? The only way to really know would be to run both and look at the surfaces, but that seems unnecessary. I would personally re-run the registration using the Schuh et al. atlas
-surface-apply-affine will transform the geometric coordinates in a *.surf.gii but will not touch metric data. It does not use flirt at all. It just uses a flirt-style transforms matrix to define the transform.
There is not any interpolation error built into the transform matrices. The only error they might contain is alignment error. The interpolation error comes from resampling a volumetric image when you apply the transformation matrix.
Fair enough, it is unfortunately confusing.
The original dHCP volumetric atlas spanned 36-44 weeks and is available at:
I augmented this original-atlas with week-to-week transforms and change some filenames for compatibility with the fMRI pipeline. The augmented original atlas is here:
For release 03, the original atlas was extended to 28-44 weeks. Unfortunately it is not exactly aligned with the original-atlas. As far as I know this has not been released yet.
I augmented this extended-atlas with week-to-week transforms, change some filenames for compatibility with the fMRI pipeline, and added transforms to the MNI and the original-atlas. It is available here:
Thank you very much for the detailed response. Trying to fully understand hcp_surface.sh, I ran it using the transformations available with the 2nd release, i.e., native to dhcp40wk.
Unfortunately, --surface-apply-warpfield returns the result on the left. On the right, the input surface :
. The documentation is scarce, and therefore I am not sure if this workbench command is supposed to completely ignore the cortical grayordinates but it clearly isn’t, for some reason. Do you have any clue what could be the problem?
In a somewhat unrelated topic: I used the script by Emma and @lzjwilliams to calculate the surface transforms from native to symmetrical surface atlas mesh. Will those be already provided with the 3rd release?
I am not really sure what you mean by “completely ignore the cortical grayordinates”?
The command --surface-apply-warpfield will transform the coordinates of the input surface to the target space of the warp. The warp you are using is non-linear and goes from a single-subject native space to a group space which is a very different space. I would not expect the transformed surface to look as smooth as the original surface…
It is not obvious to me from these images that this is a problem. What would you be expecting the transformed surface to look like?
I’ve been running all the registrations to the new symmetric atlas (using Schuh’s template to initialize the registration). I would like to know how much variability to expect in the results, for example:
This image shows the labels of two different subjects mapped to template space. Is this variability expected? and is this the correct approach to assess the quality of the registration? If not, what could be the best map to inspect? Note that this data is not from the dHCP. Thanks in advance.
Great to see you have some prelim data! Because the registrations are driven using the sulcal depth maps, I would use those to assess the registrations. What I tend to do is merge all the sulcal depth maps for each subject into a single metric file using wb_command -metric-merge, and then view these on the 40 week template space. It’s quick to flick through them in wb_view, and then get an idea of how aligned they are on the surface (and also if you think the sulcal depth maps look legitimate or too distorted). I would also look at the surfaces that have been registered to template space, just to make sure you are happy with their quality. I don’t know if I trust the parcellation on the left, given that there is a small yellow island in the middle of the parietal lobe… but if it is an isolated case it probably won’t impact any group-level analyses (if you have small numbers).
One thing you might also want to do if you are performing analyses at an ROI level is pass the surfaces through the M-CRIB-S pipeline here. This will give you regions consistent with the Desikan-Killiany atlas, and overall more granularity.
Thanks for your help! We prepared a presentation with some of the common registration inaccuracies we find in our population. Maybe is better if I send it to you by mail, it has a few images. Then you can let me know your opinion. I think probably we should change the config file for this population, but I don’t know what parameters to tune, so any feedback will be really appreciated.
For now, we are performing just voxel level analysis., but I’ll give it a try tho this segmentation. Thanks in advance!
I have a rather simple question regarding the masking of functional data on the symmetrical atlas surface. Since the medial wall mask is represented as a probability, I have been struggling to find the right approach to mask the output of -volume-to-surface-mapping. If I use it as is (anything that is not zero), I end up getting bleeding of ICs to the medial wall, but if I use it with a threshold of [0.5,0.9], I can see in individual subjects that a substantial amount of signal is lost.
I thought of an extra step so as to not to introduce spurious signal: Masking each subject which their native mask (from DrawEM tissue segmentation – unless I am mistaken – mapped to SymmAtlas space) and then dilate, before masking with a conservative (high threshold) atlas mask. What do you think of this approach?
I have been wrestling with this problem myself. The medial wall mask in the SymmAtlas is less than ideal, therefore @lzjwilliams and I have created a new medial wall mask for the atlas. The new mask is symmetrical across the hemispheres. Here is a screenshot of the mask:
I read your tips and used them.Thank you for your helpful tips.
But currently I am facing some challenges to perform surface based analysis on dhcp data.
1- First of all, I have doubts about choosing the native space or the standard space of 40 weeks of dhcp data and unfortunately I have not found a specific reason for choosing any of these spaces in the articles.
2- Correct me if I’m wrong but I think in order to use the standard 40-week space, I need to map the data (_task-rest_desc-preproc_bold.nii after masking) to the T2(masked) structural space (before volume to surface mapping) . For this step, we use the flirt command in FSL, which is due to the large number of volumes of each data, It is not possible to perform this step at once for each one.
Is there a way other than dividing the volumes, applying the transformation and merging them together? Is the final result in this method, the expected result?
3- And as the last question, somewhere you mentioned “signal loss” in dhcp data. What is the reason for this?
Sorry for the many questions. I hope to overcome these challenges with your guidance.
Hi,
Thanks for your help.I am using Schuh et al. 40w template volume for initialing the align_to_template.sh volume template variable but I just confused that we should first align the volume template to MNI space and then use the output for initialing the align_to_template.sh or It doesn’t need to align the volume template to MNI space and that script align the volume to MNI space by it self?
Best regards,
Shirin
I am slightly disoriented, are you trying to map individual BOLD data to a surface template or to a volumetric atlas space? If it is the former, I hope throughout this thread it was clear why Sean transforms the native surface from struct space to functional space before mapping onto the surface in this script.
If it is the latter, you would indeed have to first perform an affine transformation (flirt) to structural space before warping (fnirt) to the template space. Regarding acelleration of flirt, I am not aware of any way to parallelize across volumes. You can parallelize across subjects, initiating different instances of flirt in different threads. Additionally, since the dHCP preprocessed data already contains the calculated transformations from functional to structural space, you can use the -applyxfm option. (I think there was a mistake in transformation matrices in the 3rd release, which I do not know if it was resolved, maybe Logan can provide some insight).
Regardless, you should be able to do BOLD to structural space affine transformation without too much trouble as long as you don’t resample to the very high resolution of 0.5mm isometric of the T2w image. The objective is to maintain the native (low) resolution of BOLD, but register it to structural space. Take a look at “Can I register to an image but use higher/lower resolution (voxel size)?” within the flirt documentation.
Regarding signal loss, I have mainly observed very low tSNR within inferior areas of the brain, particularly the subcortical structures, explained mainly by susceptibility issues. Additionally, the occipital and prefrontal lobes sometimes present faded BOLD signal due to, I assume, susceptibility-induced inhomogeneities that are particularly acute for neonates near air/tissue interfaces. Motion might also play a role. One of the first messages from Sean on this thread refers to the HCP strategy to deal with some of these issues while mapping onto the surface, a very nifty explanation is available on his github
I hope this information was useful, let me know if you have further questions.
Hi Diego
Thank you very much for your helpful response.
I will try to use the resources you provided and will be in touch with you for further questions, of course, if you don’t mind.
Best regards
Forough
Hi Diego
I’m sorry for having another question.
Based on what you and Sean said in this topic (No.27 & 28), I’m a bit confused.
If I understand correctly, the output of “hcp_surface.sh” script is the cortical surface for each data as a cifti file in the extdhcp40wk space. Can these obtained files be used for group analysis? For example functional connectivity calculation and analysis?
Does this script include all the steps needed to map the volume to the surface (have the result in the extdhcp40wk space), or are there other things to do in the following steps?
Sorry I have been unresponsive, but I no longer work on the dHCP.
My repository has two scripts for projection of the fMRI to the surface:
dhcp/func/hcp_surface.sh - a nearly vanilla implementation of the HCP approach.
dhcp/func/surface.py - a custom method with experimental partial volume correction
I suggest you use (1) dhcp/func/hcp_surface.sh
This will yield a CIFTI containing the fMRI where the cortical vertices have correspondence to dhcp32kSym surface mesh, and the subcortical voxels will be in the extdhcp40wk volumetric space.
At this point the data is comparable across subjects and suitable for group analysis.
I hope this makes sense.
If it helps, here are some notes on coordinate systems for the dHCP functional pipeline.
I thought that these mentioned cifti data are in dhcp third data release, but it is not like this. Have these cifti datas ever been released?
And I have another question. Is there a preference between surface based analysis and volume based analysis for studying functional connectivity of dhcp data? If so, what is the reason?
