Mapping dhcp volume fmri to surface

23

Hi @lzjwilliams and @seanfitz, thanks again for your work!
I’ve tested the latest version, but it looks like the vertex correspondence issue is still present. Just wondering if there are any updates on this—has a fix been implemented or is it currently being looked into?

24

We suggest you run the deep learning pipeline instead. It’s quick and generalizes better than the old one.

25

Hi @EmmaR, thanks for your reply! I will follow your suggestion and use the deep learning based pipeline instead.

26

Hi @leonardozaggia, where you able to confirm if the DL pipeline solves the correspondence issue? Thank you!

27

Hello @EmmaR and @leonardozaggia. Unfortunately, building the cortical surfaces using the deep learning piple does not solve this issue, the vertex correspondence error keeps showing up.

28

Hi @diegoder, thanks for your update. So far, as a temporary workaround I have replaced the -ribbon-constraint option with the -trilinear method for volume-to-surface mapping.
In this setup, I used the mid-thickness surface as the target for projection.

I’m not entirely sure if this is an appropriate substitute, but it seems to work for now — I’d be curious to hear if others have insights or suggestions on this approach.

29

What do you mean by vertex correspondence issue? As the deep learning pipeline derives everything from one template with constant mesh topology then all the files must have the same number of vertices. Indeed, I just got one of my team to double check this for me.

31

Did you mean to delete the post?

Everything seems clear but last section. Do you mean it would be helpful if we generate the MSM registration outputs for you?

There is a plan for a full data release of these outputs after QC. We could include registration outputs.

I should caution that the spheres generated from the deep learning pipeline feature a very different pattern of metric distortions, which required us to regenerate the weekly templates. If you or anyone needs these urgently then we can post them somewhere.

32

I’m sorry, I didn’t want to add information until I was sure. I hope I have now organized the questions about working with the new pipeline more clearly:

  1. The MSM registration outputs (from native to vertex correspondence with dHCP 32k Symmetric surface atlas) would be most useful as the current best method is to project BOLD data onto the native mesh and then apply that registration.
  2. The regenerated weekly templates could be plugged into dHCP_template_alignment to correctly concatenate the MSM warp to the warp between local and 40-week template? In that case, I would appreciate if they were made available.
  3. The last product needed to apply the current BOLD to surface template projection is an ROI or medial wall mask. In the previous pipeline it was derived as the region with DrawEM labels and thickness greater than zero. Since there is no label product from the DL pipeline, I tried to use only thickness but the values are always positive (see attached image). Do you think there might be a better way of obtaining this mask?

Thank you!
Diego

33

Hello @EmmaR. I just wanted to provide a quick follow-up. The new Deep Learning pipeline for surface generation is blazing fast and the results look incredible, congratulations on that work! I would love to use it in my analysis, but unfortunately functional data mapping fails for same subjects as with the structural pipeline (drawEM)-generated surfaces. As an example, a subject that fails is CC00100 but CC00207 is mapped correctly.

The command from dhcp/func/hcp_surface.sh · master · Sean Fitzgibbon / dhcp-neonatal-fmri-pipeline · GitLab is

wb_command -volume-to-surface-mapping \
       ${func}.nii.gz \
       ${workdir}/midthickness_hemi-${hemi}_mesh-native_space-func.surf.gii \
       ${workdir}/func_hemi-${hemi}_mesh-native.func.gii \
       -ribbon-constrained \
      ${workdir}/wm_hemi-${hemi}_mesh-native_space-func.surf.gii \
      ${workdir}/pial_hemi-${hemi}_mesh-native_space-func.surf.gii 

ERROR: all surfaces must have vertex correspondence

So the problem seems to lay somewhere else, which is a shame given how beautiful the DL surfaces look. Maybe @lzjwilliams would know of any other differences between the 2nd and the 3rd release that may be causing this?

For completion if it helps other people: I finally generated decent enough (for my application) individual medial wall masks by binarizing the thickness metric map with a 0.4 threshold and filling in holes (‘metric-fill-holes’)