Dear Tim,

Hi. Thanks a lot to your very detailed explanation, I am more clear now about 
the underpinning relationships. :)

Just to make sure one more thing, when you mentioned "if ignoring the 
subcortical part, then everything will work with T1w surfaces", does this 
"everything" also include the GIFTI files (.func.gii) which were converted from 
the tfMRI CIFTI (.dtseries.nii) files, apart from the original CIFTI files 
themselves? Thanks!

Best regards,

在 2018-04-06 12:36:26,"Timothy Coalson" <> 写道:

On Thu, Apr 5, 2018 at 11:18 PM, Xinyang Liu <> wrote:

Dear Tim,

Hi. Lots of thanks to your very detailed answer! :)

Yes, I agree with you that it would be better to do tractography in the subject 
native volume space. And it is good to know that the MMP1.0 can be also used in 
"T1w"-space surfaces. However, there is one existed problem that I cannot 
figure out. The tfMRI outputs (e.g. tstat1.dtseries.nii) of the 
"$Subject_3T_tfMRI_$" are in the CIFTI grayordinates 
standard space, with the directory of "MNINonlinear".

CIFTI files contain both surface data and voxel-based data.  We generally only 
release cifti files that use MNI space for the subcortical voxels.  This is why 
they are in MNINonLinear, not because of the surface data.
There is no T1w folder for the native cortical surface in the tfMRI s2 file.

The surface files (.surf.gii) are in the structural packages, not in fMRI 
packages.  The fMRI CIFTI files will only have versions in the MNINonLinear 
directory, but as explained, the surface data values are not tied to any volume 
space, only the subcortical values are.  You can use T1w surfaces with the fMRI 
CIFTI files, despite them being in MNINonLinear, as long as you understand that 
the subcortical voxels will not line up properly with respect to the surfaces.  
If you only care about the cortical data, you can ignore the subcortical stuff 
entirely, and everything will work with surfaces in the T1w folder.
To do tractography in native volume space, I suppose the surface ROIs should 
also go back to the native surface. But with the only standardly registered 
tfMRI grayordinate output, how should I change back?

No, you don't need to do anything about native mesh, just use the MSMAll 
32k_fs_LR surface data with the T1w folder MSMAll 32k_fs_LR anatomical 
surfaces, and things will work.

I think you have encountered an unfortunate terminology choice on our part - 
the "native mesh" does not refer to anything related to the "native volume 
space", they are orthogonal concepts.  "Native mesh" just means the 
subject-specific, haphazard mesh that comes out of freesurfer (approximately 
140k vertices per hemisphere, as I recall).  This doesn't prevent the 
application of volume registration to their coordinates - indeed, there are 
"native mesh" surfaces in the MNINonLinear folder, where this is exactly what 
we did.  However, you don't need to use them, or the native mesh surfaces in 
T1w space either.
Best regards,

At 2018-04-05 04:54:04, "Timothy Coalson" <> wrote:

Inline replies to some comments.


On Wed, Apr 4, 2018 at 7:38 AM, Xinyang Liu <> wrote:

Dear Matthew,

Thank you very much for your detailed explanation!

1. The current situation of our study is that, we used the HCP MMP1.0 atlas to 
sample the tfMRI data in order to localize specific functional areas. Since the 
HCP MMP1.0 is in the MNI space,

No, it isn't, because version 1.0 is a surface-only parcellation.  
Surface-based labels or scalar data are not in any volume space, it is only the 
geometry files (*.surf.gii) that have any coordinates in them at all.  It is 
also correct to use the MMP1.0 with "T1w"-space surfaces (MSMAll is 
we used 
 to do the multiplication. Then I suppose the surface ROI to be acquired in the 
MNI standard space, and therefore need to use the --xfm and --invxfm in 
probtrackx2. Is my understanding correct?

As I understand it, tracking in subject native (T1w) volume space is strongly 
recommended, because the nonlinear MNI warp could change the paths that 
tractography takes to be something unrealistic.  The T1w space is an 
undistorted, rigid aligned version of the scanner space of the anatomical 
images (and the T1w space diffusion data has had its vectors rotated to match 
this rigid alignment), and thus the white matter is the same shape as it is in 
the subject's head.
2. In this way, do the HCP data contain files that can be used in --xfm, 
--invxfm and --seedref in surface prob-tracking?

3. In the FSL "surf2surf" format conversion from .func.gii to ASCII type 
(.asc), is it correct to use 
as the input (-i) and the acquired "ROI.func.gii" as --value? 

I haven't used this, I would say try it and see what happens.  Maybe someone 
else can tell you what they did.
Look forward to your kind guidance. Thanks a lot!

Best regards,

At 2018-04-04 18:44:25, "Glasser, Matthew" <> wrote:

1.  Files in ${StudyFolder}/${Subject}/T1w are in subject’s physical space and 
files in ${StudyFolder}/${Subject}/MNINonLinear are in MNI standard space.  
Surfaces without MSMAll are registered with MSMSulc and surfaces with MSMAll 
are registered with MSMAll.  In general MSMAll will have better alignment of 
cortical areas across subjects.

2.  There is no native diffusion space, as this is unnecessary.  Tracking 
occurs subject’s physical space and you can use the surfaces in 
${StudyFolder}/${Subject}/T1w/fsaverage_LR32k with MSMAll if you don’t use 
--xfm and --invxfm or those in 
${StudyFolder}/${Subject}/MNINonLinear/fsaverage_LR32k if you do.



From: Xinyang Liu <>
Date: Wednesday, April 4, 2018 at 2:36 AM
To: Matt Glasser <>
Cc: HCP 讨论组 <>
Subject: Re: [HCP-Users] questions about using HCP surface ROIs in prob-tracking

Dear Matthew,

Thank you very much for your kind reply!

Could I continue asking two more new questions?

1. In the preprocessed structural data, both the 
/${Subject}/T1w/fsaverage_LR32k and /${Subject}/MNINonLinear/fsaverage_LR32k 
contain white surface files with the same names, such as 
"${Subject}" and 
"${Subject}".  Is there any difference 
between these files of the same name but under different routes?

2. I am kind of confusing about the space transformation in surface ROI fibre 
tracking. In the volume-based analysis, there is native diffusion space and 
standard space, and tractograhpy is done in native diffusion space. For surface 
data, I suppose the files like "${Subject}" have 
already been registered to a 32k standard mesh. Then should the surface ROI 
fibre tracking go back to native space and how if needed?

Best regards,

At 2018-04-04 00:49:09, "Glasser, Matthew" <> wrote:

1.  Yes, though they can come from a certain (configurable) radius around the 
vertex, rather than all from the point location with --sampvox.

2.  I think probtrackx2 looks for greater than zero, but you could of course 
binarize them.

3.  I believe you can display the surface counts in GIFTI format with --fopd, 
you might ask more on the FSL list as I haven’t done much tractorgraphy in a 



From: <> on behalf of Xinyang Liu 
Date: Tuesday, April 3, 2018 at 1:52 AM
To: HCP 讨论组 <>
Subject: [HCP-Users] questions about using HCP surface ROIs in prob-tracking

Dear HCP experts,

Hi. As a new learner of the HCP tfMRI surface data, I have some questions when 
using them as ROIs to do probabilistic tractography. I would be very thankful 
to receive any of your kind guidance. My questions are as below.

1. I know that in FSL probtrackx2 voxel-based fibre tracking, 5000 streamlines 
(default) come out from each voxel. How about the case in the surface vertices 
of the HCP grayordinate space? Is it similar with the voxel-based tracking, 
like 5000 streamlines coming out from each vertex?

2.The tfMRI surface ROIs usually contain information of signal intensities, 
would this influence the diffusion tracking results if using them as masks?

3. How to display the surface ROIs (.func.gii or .asc) and output tracking 
paths (.nii.gz in FSL results) in the same figure? 

Look forward to your feedbacks. Thank you very much!

Best regards,
Xinyang Liu


HCP-Users mailing list



HCP-Users mailing list


HCP-Users mailing list

Reply via email to