fs_average to MSMAll space

[Austin Cooper]

Hi there again neuroscience aficionados,

I'm hoping that you can guide me in the right direction when it comes to anatomical alignment and registration between atlases. 

I've run my movie-fMRI data  through the entire HCP pipeline and have MSMAll aligned data for all of my subjects. I also have a retinotopic based atlas that is in both fsaverage_sym space and to subject specific recon-all surface files.

I'd like to find a way to transfer this retinotopic based atlas into the same space as my HCP-pipeline preprocessed data so that I can reap the benefits of the MSMAll method. The atlas is in .sym.mgh format for the fsaverage_sym alignment and .mgz format for the subject specific recon-all surface files.

If you could inform me as to if this is possible and provide some basic pointers then I'd be very appreciative!!

Warm regards from Montreal,

Austin

[Glasser, Matt]

Does Freesurfer have a transformation between fsaverage_sym and fsaverage?  We made FS_LR years ago for this same purpose, but evidently, they chose to create their own version.  To go between fs_LR and fsaverage, you can use the following instructions:

 

https://wiki.humanconnectome.org/download/attachments/63078513/Resampling-FreeSurfer-HCP_5_8.pdf

 

Matt.

--
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/e00f52bc-8066-40d5-bd0b-953e1fd9ff6en%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.

[Austin Cooper]

Thanks Matt!

The link, though, doesn't work for me. I've tried on a couple different devices, browsers, and internet connections. 

Any chance you can send the PDF directly here?

Warm regards,
Austin

[Austin Cooper]

The link works now! Seems the website was under maintenance. 

Thanks Matt!

[Austin Cooper]

Hi Dr. Glasser,

I've followed the steps in the tutorial but now run into an error which makes me doubt if what I want to do is possible. 

I successfully ran step 1 for section B FreeSurfer native individual data to fs_LR ), but for step 2 I receive an error saying that "input metric has different number of nodes than input sphere"

The command I submit is:

wb_command -metric-resample $atlas/rh.wang15_mplbl.func.gii $fs_LR/20.R.sphere.32k_fs_LR.surf.gii \

    $resample/fs_LR-deformed_to-fsaverage.R.sphere.32k_fs_LR.surf.gii \

    ADAP_BARY_AREA $output/20.wang15_mplbl.R.32K_fs_LR.func.gii  -area-surfs \

    $output/rh.midthickness.surf.gii $output/20.R.midthickness.32k_fs_LR.surf.gii

So I suppose that the atlas which I want to convert to fs_LR (rh.wang15_mlbl.func.gii) does not have 32K vertices. I also tried the command with the input sphere of 164K vertices, but still no luck.

Is there a command that can inform me of the number of vertices in rh.wang15_mlbl.func.gii?

[Tim Coalson]

wb_command -file-information will tell you.  The output sphere of step 1 is not a 32k fs_LR sphere, so you shouldn't put that in its file name, it is actually just the converted registered native sphere for the subject.

I think you said your data is on "fsaverage_sym", which is not any subject's native mesh, so section B is not the right instructions to follow.  The resampling steps we detail are for ordinary fsaverage to fs_LR, not fsaverage_sym, and we haven't prepared files to make it convenient to resample to/from _sym (yet?).  For a quick answer, you can resample twice, once to normal fsaverage, and then use steps similar to section A to get to fs_LR.

In order to get to fs_LR with a single resampling (as opposed to recalculating the answer with fs_LR-registered individual data), you will need to concatenate the atlas registration of _sym to fsaverage onto our fsaverage to fs_LR atlas registration.  I don't know the details of fsaverage_sym, but you will likely need two additional deformed spheres, representing the difference between the fsaverage_sym and standard fsaverage atlases.  It would be nice if these were provided by the creators of _sym, but I suspect they aren't...making them requires deciding whether you trust the _sym registration or standard fsaverage registration more for cross-subject purposes.  Then, you take the spheres that represent the standard to _sym registration (or its reverse by using -surface-sphere-project-unproject, depending on that decision) for each subject, average them per-hemisphere with wb_command -surface-average, and restore their sphericity with -surface-modify-sphere (don't use -recenter).  Effectively, this computes the "drift" between the two atlases, for the given group of subjects.

If these spheres are "fsaverage deformed to _sym", it needs to be a two-step process: first, do "wb_command -surface-sphere-project-unproject <_sym standard sphere> <fsaverage sphere deformed to _sym> <fsaverage standard sphere> <output>", which will produce a _sym sphere deformed to standard fsaverage space.  You can then proceed as below:

Once you have "_sym deformed to normal fsaverage" spheres (either from the start, or via the above command), you can do "wb_command -surface-sphere-project-unproject <_sym sphere deformed to fsaverage> <164k fs_LR-deformed_to-fsaverage sphere> <164k fs_LR standard sphere> <output>", which will generate an _sym sphere that is aligned to the fs_LR atlas, which you can use as <current-sphere> in any resampling command, along with any desired resolution fs_LR standard sphere.

Technically, you could use the "_sym deformed to normal fsaverage" sphere and any "fs_LR deformed to fsaverage" sphere directly in any resampling command, but that might be harder to understand.

Unfortunately though, since _sym is a separate atlas from fsaverage, we don't have precomputed average vertex areas for it, so adaptive barycentric resampling would need additional preparation (its main purpose is to prevent SNR inefficiency when downsampling, which may not be a concern, depending on the type of data).  The basic process is to have many subjects with their midthickness surfaces registered and resampled to both surface atlases, run wb_command -surface-vertex-areas on all of them, and average the results (within hemisphere and atlas).  No, averaging the surfaces is not a substitute, the point of this process is to avoid the loss of group-average surface area caused by human cortical folding variability, which can't be fully aligned.

Tim

To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/4f49aa9a-2224-41cb-b59c-24f21a307cben%40humanconnectome.org.

[Austin Cooper]

Tim, thank you very much for your explanation!

I want to clarify that I have my atlas file in both fs_sym and also in my subject-specific surface space. Based on what you've said I'm led to believe that using the subjects specific surface space is likely the easiest route.

I've come to realize, though, that my problem likely occurs when converting my subject's .mgz atlas file into .gii. I had used mri_convert atlas.mgz atlas.gii  to do this, but when I assess the newly created .gii file with  "wb_command -file-information" I see that it has only ONE vertex, haha.

I then tried to use mris_convert instead, thinking this would be the fix, but instead I receive a multitude of "freadFloat: fread failed" errors. If, instead of the subject specific .mgz atlas, I try instead to convert the template atlas (which is a .mgh file and is located in what I believe to be fs_sym space) to .gii format, then I get the following error: "ERROR: MRISread: file 'V123-template-2.5.sym.mgh' has 0 vertices!
Probably trying to use a scalar data file as a surface!". 

What I know about subject specific .mgz atlas is that it contains one value per vertex; those values are integers (such as 1, 2, or 3 for V1, V2, V3 and 0 for unlabeled).

It seems to me that if I cannot sort out how to convert the atlas file to .gii in a reasonable manner then I will not be able to proceed with any of the steps that you have thoroughly mentioned.

Do you have a hunch as to what could be going wrong with the data type conversion?

Warmest of regards,

Austin Cooper

[Tim Coalson]

When I see .mgz, I expect it to be a volume file, not a surface-based file.  What does it look like when you view it in, say, freeview?  How did you generate it, and can you save it to a format other than mgz in the first place?

Tim

[Glasser, Matt]

I think it can be both.  I don’t know what to do with it if it is not a volume file though.

Matt.

[Austin Cooper]

The atlas file contains 1 value per surface vertex on the subject's respective hemisphere (in a 1x1xN volume). 

Do you reckon that the "B. FreeSurfer native individual data to fs_LR" option in  https://wiki.humanconnectome.org/download/attachments/63078513/Resampling-FreeSurfer-HCP_5_8.pdf is the right way to go about things? I'm not sure the proper way to convert this .mgz file into .gii. This is the first step needed, so it seems to me. Is it possible?

Thanks for your help :)

[Tim Coalson]

If you can get it into a .gii file with the subject's native mesh, then yes, section B is correct.

I'll also note that the subject's native mesh is generally more than 100k, which exceeds the nifti-1 limit of 32k in a single dimension, so your .mgz format file probably can't be converted as-is to nifti-1, so you can't easily deal with the conversion problem in external tools instead.

I'll ask again, can you go back to the command/code that generated it, and save it in a format that isn't .mgz?  Otherwise, you may need to ask the freesurfer list how to turn your not-really-volume-file back into a surface format.

Tim

[Austin Cooper]

Thanks Tim!

Sorry for the delay, I'm still working on this one and have redirected some of my efforts to the issue described below:

As for now, I'm trying to convert the volume-based version of my retinotopic visual cortex atlas to MNI space such that I can overlay it on top of the HCP preprocessed volume-based fMRI data of mine. The atlas is initially applied to the subjects native surface, and then it is converted to their native T1. So I have .nii.gz files of the atlas in native T1 space.

Does the HCP pipeline provide the transformation files between the volume-based native T1 and the MNI aligned T1 that I could then apply to the atlas? 

Would they be found in MNINonLinear/xfms? My first guess is that it is either acpc2MNILinear.mat or acpc_dc2standard.nii.gz, but when I apply for the following commands for the respective transformation files:

# Define paths to input files
native_T1="$subject/MNINonLinear/T1w_restore_brain.nii.gz"
linear_transformation="$subject/MNINonLinear/xfms/acpc2MNILinear.mat"
nonlinear_transformation="$subject/MNINonLinear/xfms/acpc_dc2standard.nii.gz"

# Apply linear transformation
flirt -in "$native_T1" -ref "$native_T1" -applyxfm -init "$linear_transformation" -out "${output_dir}/linear_transformed.nii.gz"

# Apply non-linear transformation
applywarp --ref="$native_T1" --in="$native_T1" --warp="$nonlinear_transformation" --out="${output_dir}/nonlinear_transformed.nii.gz"

I end up with a volumetric file that does not nicely align with the MNI template, unlike my fMRI  files which do.

Any pointers?

Austin

[Glasser, Matt]

acpc_dc2standard.nii.gz is the transformation to MNI space.  MNI space is not the place you want to be making cortical comparisons across subjects.

[Tim Coalson]

I think that warpfield includes the affine component, and transforms from T1w space to MNI space, using the structural standard volume space headers (note, FSL-convention transforms like these are only guaranteed to work for the original volume headers they were generated for - I believe we generated our various-resolution standard volume space headers so that they still work across them, but it is still something to be aware of).

Why do you want to look at a surface-based atlas (and fMRI data) in the volume?  We recommend the cifti-format fMRI data, rather than the volumetric timeseries (the main reason this is generated in MNI space is for the subcortical alignment, and we didn't want to generate a second full volume timeseries in T1w space just for surface mapping).

Tim

[Austin Cooper]

My code was initially written for volume-based data, and so I want to get it functioning before I convert it to work with surface data. It's not functionable now since the atlas is not overlapping with my MNI-aligned fMRI data.

The atlas itself is applied to the subject's native surface mesh and then transformed into their /T1w/mri/orig.mgz volume. The scripts that I have right now only function when the fMRI volume data, anatomical data, and atlas data are all aligned, which is not the case, since the atlas is in the freesurfer original anatomical space and the fMRI is in MNI space. 

One option could be to convert the minimally pre-processed fMRI data  back into native space, or the other option is what what I'm trying to do which is to convert the atlas file into the subject's MNI transformed space. Do you have any recommendations as to one over the other?

Also, when I use  /MNINonLinear/xfms/acpc_dc2standard.nii.gz to transform /T1w/mri/orig.nii.gz (I converted orig.mgz to orig.nii.gz) to /MNINonLinear/T1w_restore.nii.gz (-ref), I don't get an output image aligned to MNI. I figure there is a flaw with my command:

input_file=$path/mri/orig.nii.gz
transformation_file=$path/MNINonLinear/xfms/acpc_dc2standard.nii.gz
reference_file=$path/MNINonLinear/T1w_restore.nii.gz
output_file=/project/6001995/coopapap/results/ONs/debbie/control/movie/06_scan1/avg_images/acpc_to_mni_fsl.nii.gz

# Apply transformation using applywarp
applywarp --in=$input_file \
          --ref=$reference_file \
          --warp=$transformation_file \
          --out=$output_file

Could it also be that the transform file is intended for /T1w/T1w_acpc_dc.nii.gz? Does this mean I need to apply 2 transform files to my atlas, first from orig.mgz to T1w_acpc_dc.nii.gz and then from T1w_acpc_dc.nii.gz to T1w_restore.nii.gz?

[Glasser, Matt]

FreeSurfer’s and HCP’s spaces are not aligned.  You need to do something like mri_convert -rt nearest -rl rawavg.mgz "$Image".mgz <output>

 

Matt.

 

From: Austin Cooper <austin....@gmail.com>

Reply-To: "hcp-...@humanconnectome.org" <hcp-...@humanconnectome.org>
Date: Thursday, February 22, 2024 at 1:26 PM
To: HCP-Users <hcp-...@humanconnectome.org>

To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/d8512460-a51e-4f45-ad60-831c8a824209n%40humanconnectome.org.

[Tim Coalson]

Or, when mapping the surface atlas to volume, use wb_command -label-to-volume-mapping, and use the HCP surfaces in the desired output space, instead of involving orig.mgz.

Tim

[Austin Cooper]

Hey Tim! I'll try this method.

I converted my surface-based native-subject-mesh atlas files $hemi.benson14_varea.mgh into .gii format by using the following command: 

mris_convert -c $hemi.benson14_varea.mgh $hemi.white $hemi.benson14_varea.gii. 

I did this because it seems that  wb_command -label-to-volume-mapping requires the input file to be in .gii format. What I know about subject specific .mgh atlas is that it contains one value per vertex; those values are integers (such as 1, 2, or 3 for V1, V2, V3 and 0 for unlabeled), so I thin the -c flag (used to indicate a scalar file) is correct.

Though, after running: 

wb_command -label-to-volume-mapping -nearest-vertex 1 $subject_dir/surf/rh.benson14_varea.gii $subject_dir/surf/rh.white.gii $subject_dir/MNINonLinear/T1w_restore.nii.gz $subject_dir/MNINonLinear/atlas/rh_benson.nii.gz (where the structure is wb_command -label-to-volume-mmapping -nearest-vertex $vertex_distance $native_atlas $native_surface $volume_to_align_to $output_atlas).

I receive:

WARNING: label file '/project/6001995/Shmuel_Mendola/Data/MGH/HCPNaming/control/06_scan1/surf/rh.benson14_varea.gii' contains data array with data type other than int32

WARNING: input label file has structure 'INVALID', while the surface has structure 'CORTEX_RIGHT'

I then tried to run the wb_command -metric-to-volume-mapping instead, with all other options of the command remaining the same. This still receives the WARNING: input metric file has structure 'INVALID', while the surface has structure 'CORTEX_RIGHT', but that is all. When I open the output $subject_dir/MNINonLinear/atlas/rh_benson.nii.gz file I see that the visual cortex atlas is not aligned with the $subject_dir/MNINonLinear/T1w_restore.nii.gz (see attached image). Do you see any flaws with my command? Do you have an idea as to what volume this atlas is now aligned to?

[Austin Cooper]

Tim, I see you say:  "and use the HCP surfaces in the desired output space" and that I used the surface in my subjects freesurfer folder. I presume this is where the issue lies, but I'm not sure what surface to use, a surface that can transform the atlas to the MNI space of  $subject_dir/MNINonLinear/T1w_restore.nii.gz

sorry for the double email.

Austin

[Tim Coalson]

Use the surface files in the MNINonLinear folder if you want to overlay it on an MNINonLinear volume.  T1w space and MNINonLinear space are not the same.

I suggest doing wb_command -set-structure and -metric-label-import on the converted atlas file, to resolve the warnings and mark it as categorical data (which shouldn't be interpolated).

Tim

[Austin Cooper]

Hey Tim! Thanks for the clarification. I refer to the T1 which is aligned to the MNI template, T1w_restore.nii.gz  since this is the file I want my atlas to be aligned to.

Great news is that using the pial surface within /MNINonLinear/native worked wonders and now my atlas is aligned to the subejct's MNI space. 

Thank you very very much!!

[Austin Cooper]

Hi there! Hoping you're well!

I've come back to this topic of converting my subject-specific atlas to fs_LR space. I've been able to convert 2 atlases to fs_LR space successfully using instructions from these HCP resampling instructions (specifically section B). The code that works has been:

wb_shortcuts -freesurfer-resample-prep ${fs_white} ${fs_pial} ${current_freesurfer_sphere} \

        ${new_sphere} ${midthickness_current_out} ${midthickness_new_out} ${current_gifti_sphere_out}

eccen_in=lh.benson14_eccen.gii

area_in=lh.benson14_varea.gii

new_area=$midthickness_new_out

eccen_out=$subject.benson_eccen.$hemi.32K_fs_LR.func.gii

area_out=$subject.benson_varea.$hemi.32K_fs_LR.func.gii

wb_command -metric-resample $eccen_in $current_gifti_sphere_out $new_sphere ADAP_BARY_AREA $eccen_out -area-surfs $midthickness_current_out $new_area

wb_command -metric-resample $area_in $current_gifti_sphere_out $new_sphere ADAP_BARY_AREA $area_out -area-surfs $midthickness_current_out $new_area

This code goes through without error. Though when I open the output files with workbench it says that the files have a missing or invalid structure.

Could you explain how to prevent this, such that I don't have to select CortexLeft from the dropdown?

Warmest regards,

Austin

[Glasser, Matt]

wb_command -set-structure.

[Austin Cooper]

That's perfect. Thanks Matt! I didn't realize it was so easy.

New question, I see that within the newly transformed atlas (atlas transformed from native freesurfer mesh to fs_LR_32K mesh via -metric-resample) that many of the values which were originally whole numbers ranging from 1-12 (representing 12 distinct cortical regions of the visual processing stream) are now decimal values.

I'd just like to confirm that this is likely because of the down-sampling of the resolution and thus is resulting in vertices that are classified as a mixture of regions. If I'm right about this, do you htink it would be wiser to use higher resolution data for both atlas and fMRI data?

Warm regards,

Austin

[Tim Coalson]

Categorical data shouldn't be in metric files, it should be in label files.  See -metric-label-import.

Tim

[Austin Cooper]

That's great, thanks Tim!!

I used -label-resample and that fixed the issue.

Now that I've got my atlases loaded into fs_LR space I need to choose the data to use. 

For curiosity sake I'm wondering if you can explain the difference between tfMRI_MOVIE1_AP_Atlas_MSMAll_hp0_clean.dtseries.nii and tfMRI_MOVIE1_AP_MSMAll.${hemi}.atlasroi.32k_fs_LR.func.gii when it comes to the cortical data?

I've loaded them both into workbench onto the fs_LR surface and I can see some very subtle differences when it comes to activation, but more similarities than differences.

I briefly checked your 2013 paper (The minimal preprocessing pipelines for the Human Connectome Project) but didn't find the relevant information.

Any quick guidance would be great.

Warm regards,

Austin

[Glasser, Matt]

Use the CIFTI file.  That GIFTI file is a processing intermediate.

Error! Filename not specified.

[Austin Cooper]

Okay, thanks Matt! Greatly appreciated.

I've set my scripts  up initially to work with the gifti data, via using the gifti matlab toolbox, which loads each hemisphere separately, where each hemi's respective cdata is a 32492×210 single. Though, when I load the whole brain cifti file through the cifti matlab code you have developed I see that the cdata is a 91282x210 single. 

Is there any easy way to pull the two 32492×210 singles (1 per hemi) from this  91282x210 single, via matlab?

Austin

[Tim Coalson]

Use cifti_struct_dense_extract_surface_data.  When you want to put data back into cifti format, see the similar ...replace_structure functions.

Tim