Yes, vertex-based data is not tied to any volume space, whether it is
stored in cifti or gifti.
Tim
On Sun, Apr 8, 2018 at 5:27 AM, Xinyang Liu <xinyang_ie...@163.com> wrote:
> 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,
> Xinyang
>
> 在 2018-04-06 12:36:26，"Timothy Coalson" <tsc...@mst.edu> 写道：
>
> On Thu, Apr 5, 2018 at 11:18 PM, Xinyang Liu <xinyang_ie...@163.com>
> 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_$TASK_analysis_s2.zip" 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,
>> Xinyang
>>
>>
>> At 2018-04-05 04:54:04, "Timothy Coalson" <tsc...@mst.edu> wrote:
>>
>> Inline replies to some comments.
>>
>> Tim
>>
>> On Wed, Apr 4, 2018 at 7:38 AM, Xinyang Liu <xinyang_ie...@163.com>
>> 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
>> recommended).
>>
>>
>>> we used
>>> "$SUBJECT/MNINonLinear/fsaverage_LR32k/$SUBJECT.L.midthickness._MSMAll.32k_fs_LR.surf.gii"
>>> 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 "$Subject/MNINonLinear/fsavera
>>> ge_LR32k/${Subject}.R.white.32k_fs_LR.surf.gii" 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,
>>> Xinyang
>>>
>>>
>>>
>>> At 2018-04-04 18:44:25, "Glasser, Matthew" <glass...@wustl.edu> 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.
>>>
>>> Peace,
>>>
>>> Matt.
>>>
>>> From: Xinyang Liu <xinyang_ie...@163.com>
>>> Date: Wednesday, April 4, 2018 at 2:36 AM
>>> To: Matt Glasser <glass...@wustl.edu>
>>> Cc: HCP 讨论组 <hcp-users@humanconnectome.org>
>>> 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}.L.white.32k_fs_LR.surf.gii" and
>>> "${Subject}.L.white.MSMAll.32k_fs_LR.surf.gii". 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}.L
>>> .white.32k_fs_LR.surf.gii" 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,
>>> Xinyang
>>>
>>>
>>> At 2018-04-04 00:49:09, "Glasser, Matthew" <glass...@wustl.edu> 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 while.
>>>
>>> Peace,
>>>
>>> Matt.
>>>
>>> From: <hcp-users-boun...@humanconnectome.org> on behalf of Xinyang Liu <
>>> xinyang_ie...@163.com>
>>> Date: Tuesday, April 3, 2018 at 1:52 AM
>>> To: HCP 讨论组 <hcp-users@humanconnectome.org>
>>> 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@humanconnectome.org
>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> HCP-Users mailing list
>>> HCP-Users@humanconnectome.org
>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>>
>>
>>
>>
>>
>>
>
>
>
>
>
_______________________________________________
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users
