Different visualization of surface and volume alignment under wb_view and freeview

294 views
Skip to first unread message

Zack Guo

unread,
Jul 27, 2024, 8:50:21 AM7/27/24
to HCP-Users
Hi,

When I visualized the alignment of surface and volume in wb_view and freeview, I found the results were different. Take the data of subject 100307 as example.

Individual T1w volume file: 100307/T1w/T1w_acpc_dc_restore.nii.gz
Individual surface files from HCP Pipelines: 100307/T1w/Native/100307.${hemi}.pial.native.surf.gii, 100307/T1w/Native/100307.${hemi}.white.native.surf.gii T1w
Individual surface files from freesurfer: 100307/T1w/100307/surf/${hemi}h.pial, 100307/T1w/100307/surf/${hemi}h.white
I converted these files to surf.gii using mris_convert for visualizing in wb_view:
mris_convert 100307/T1w/100307/surf/${hemi}h.pial 100307/T1w/100307/surf/${hemi}h.pial.surf.gii mris_convert 100307/T1w/100307/surf/${hemi}h.white 100307/T1w/100307/surf/${hemi}h.white.surf.gii

In wb_view, the first group of files aligns with T1w, while the second group does not.
In freeview, it is the opposite: the second group of files aligns with T1w, whereas the first group does not.

How to understand it? Thanks!

1.png2.png

Glasser, Matthew

unread,
Jul 27, 2024, 10:07:20 AM7/27/24
to hcp-...@humanconnectome.org

This is probably the cras offset, which you can deal with using the --to-scanner flag of mris_convert.  That said, all of these conversions are already done by the HCP Pipelines, so it isn’t clear why you are redoing them.


Matt.

 

 

Hi,

 

 

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/a2570d3c-a483-4e9b-8702-646ce18ed1fen%40humanconnectome.org.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

Zack Guo

unread,
Jul 27, 2024, 11:38:53 AM7/27/24
to HCP-Users, glas...@wustl.edu
Hi Matt,

Thank you for your answer.

I find the code that deals with the c_ras offset in the FreeSurfer2CaretConvertAndRegisterNonlinear.sh script within the HCP Pipeline. However, I am puzzled as to why the same files visualize differently in wb_view and freeview.
My objective is to use the surface at the gray-white matter interface (i.e., the pial file) as a seeding surface for streamlines tracking. Based on my understanding, the dMRI and T1w data preprocessed by HCP Pipelines are already aligned, so the choice of surface is important. I would like to clarify which group of surface files I should use.

Zack.

Glasser, Matthew

unread,
Jul 27, 2024, 11:41:46 AM7/27/24
to hcp-...@humanconnectome.org

In general, there isn’t a reason to use the data in the FreeSurfer folder.  You can use the white surfaces in ${StudyFolder}/${Subject}/T1w/fsaverage_LR32k.  Typically,  it is better to use the MSMAll aligned surfaces.

Image removed by sender.Image removed by sender.

 

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/a2570d3c-a483-4e9b-8702-646ce18ed1fen%40humanconnectome.org.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.

Zack Guo

unread,
Jul 27, 2024, 12:25:21 PM7/27/24
to HCP-Users, glas...@wustl.edu
Hi Matt,

Thanks again.

I have another question I would like to ask. From my understanding, the fs_LR32k fMRI data (e.g.  ${StudyFolder}/${Subject}/MNINonlinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_Atlas_MSMAll.dtseries.nii) is derived from volume fMRI data which is registered to MNI space (please correct me if I'm wrong).

And could you please advise me on how to obtain the fs_LR32k fMRI data in individual native space for personalized analysis?

Zack.

Glasser, Matthew

unread,
Jul 27, 2024, 12:40:36 PM7/27/24
to hcp-...@humanconnectome.org

That isn’t super easy to do.  These are huge files, and we did not elect to generate two copies of them. 

 

I would use the data with _hp2000_clean so that you have cleaned data.

Error! Filename not specified.Error! Filename not specified.

 

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/a2570d3c-a483-4e9b-8702-646ce18ed1fen%40humanconnectome.org.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.

Zack Guo

unread,
Jul 27, 2024, 11:52:37 PM7/27/24
to HCP-Users, glas...@wustl.edu
Thanks. Could you point out some key steps or commands for this process? 

Tim Coalson

unread,
Jul 29, 2024, 4:47:46 PM7/29/24
to hcp-...@humanconnectome.org, glas...@wustl.edu
For legacy reasons, freesurfer has different coordinate systems for surface and volume data, and applies an offset between them before displaying data.  mris_convert --to-scanner corrects for this difference between surface and volume coordinate systems, so that the coordinate values in the surface files actually line up with the image in the volume file.  When these surfaces are loaded back into freeview, it still expects the surface and volume to be in different coordinate systems, so it displays the surface in the wrong place.

Tim


Tim Coalson

unread,
Jul 29, 2024, 4:53:16 PM7/29/24
to hcp-...@humanconnectome.org, glas...@wustl.edu
Surface-based data files (metric, cifti) do not have surface coordinates embedded in them.  The surface coordinates are only in the .surf.gii files.  You can display/process the fs_LR 32k data on the T1w 32k surfaces and it is perfectly valid, despite the MNINonLinear space having been used for mapping the data to the surface.  Only voxel-based data (volume files, subcortical data in cifti) has the limitation that the data is implicitly tied to a coordinate space.

Tim


Zack Guo

unread,
Jul 30, 2024, 12:58:34 AM7/30/24
to HCP-Users, tim.c...@gmail.com, glas...@wustl.edu
Hi Tim,

Thank you for your clear reply.

Zack.

Zack Guo

unread,
Jul 30, 2024, 1:17:57 AM7/30/24
to HCP-Users, tim.c...@gmail.com, glas...@wustl.edu

Hi Tim,

Thank you for your response again!

I want to map the native volume fMRI data to native fs_LR32k surface (${StudyFolder}/${Subject}/T1w/fsaverage_LR32k) for individualized analysis. Therefore, I might need to reprocess the raw data. I downloaded a subject's unprocessed data for testing, but I am not quite sure about the meaning of some files, such as  ${Subject}_3T_BIAS_32CH.nii.gz and  ${Subject}_3T_BIAS_BC.nii.gz in directories T1w_MPR1, rfMRI_REST1_LR, etc. Are these files necessary for preprocessing?

By the way, is there any other better suggestions for this purpose?

Zack.

Tim Coalson

unread,
Jul 30, 2024, 3:37:32 PM7/30/24
to Zack Guo, HCP-Users, glas...@wustl.edu
What do you expect to gain from that effort?  The fnirt warpfield we use is fairly gentle, so it shouldn't have large effects on the final local smoothness of the surface data, and we transform the surfaces to match before mapping to surface, if that wasn't obvious (so we are still grabbing the same part of the individual's cortex at each vertex compared to using T1w space for everything), and surface registrations don't care about the volume space (they don't use anatomical coordinates, and the subject's spheres are derived from T1w space).  Our result should be nearly identical to the result of what you propose, which is why we decided not to make yet another copy of the volume timeseries.

The 32CH (head coil) and BC (body coil) files are for receive field correction.  In HCP-YA we didn't enable prescan normalize on the scanner.

Tim

Reply all
Reply to author
Forward
0 new messages