I think you are close, but there may be some terminology confusion. Inline comments.
Tim On Fri, Jul 20, 2018 at 12:34 AM, Aslan Satary Dizaji <[email protected] > wrote: > Thank you very much for your response. > > The reason that we use MATLAB based functions to read data is that we want > to perform batch pipeline for the whole analysis of 100 unrelated subjects > data-set. > ciftiopen.m, etc, are MATLAB based functions. However, they don't load spatial information, we do all our spatial operations in scripts using wb_command (MATLAB is not ideal when you want to use a cluster to process a lot of subjects). There are wb_command operations that can give you text and gifti files that can be loaded in matlab to give you this information, but from what you have said you wanted to do, I think you would be better off using the wb_command operation designed for mapping between surface and volume, rather than implementing similar code in matlab. Improving matlab support for cifti is on the list of things to do, but with several things above it. > To sum up our conversations: > > The coordinates of surface time-series of Resting State fMRI FIX-Denoised > (Compact) data-set of 100 unrelated subjects lie in the folders " > MNINonLinear/fsaverage_LR32k" of Structural Preprocessed data-set of 100 > unrelated subjects. It is better that we use MSMAll version of > "*.dtseries.nii" files and midthickness_MSMAll version of "*.surf.gii" > files. > Correct so far. > Also, the coordinates of surface time-series are not in the MNI space, so > to apply a MNI mask on these coordinates, it is better that we put the MNI > mask from the volume-space to the surface-space of a representative number > of subjects by using HCP workbench. > Close, perhaps simply a wording issue - surface-based data doesn't inherently have a millimeter coordinate space it is tied to. We provide surface files (which DO contain coordinates) in both MNI space and "T1w" space (really, distortion corrected rigidly aligned space), and you can choose between them depending on your task. Because the timeseries data is already in surface format, moving it back to volume format would cause degradation (and worse alignment), it is generally better to move the ROI to the format the data is in. Since the ROI is a volume-based MNI-space file, you need to use MNI-space surfaces to figure out where on the surface it should be, and using multiple subjects allows you to see the registration uncertainty in translating between MNI volume alignment and MSMAll surface alignment (and also avoids the issues with group-average surface coordinates). > One last question: if we don't use a mask and we do some analysis on the > whole subcortical plus surface time-series, how can we summarize the > results over > the whole group of subjects? I mean can we average the results over > corresponding indices of time-series among all subjects? > Surface-format files, after registration and resampling to the same template (in this case, MSMAll) and standard mesh (in this case, 32k_fs_LR), can be compared/combined across subject by index, just like volume files. CIFTI files continue this idea to both hemispheres and subcortical voxels simultaneously, as long as you use not only the same registrations/resamplings, but also the same set of brainordinates (in this case, the 91282 standard grayordinate space). > Thank you again for your time and consideration. > > Best regards, > > Aslan > > On Fri, Jul 20, 2018 at 12:08 AM Timothy Coalson <[email protected]> wrote: > >> ft_read_cifti.m does extra stuff that may be confusing, we don't do >> spatial operations in matlab. >> >> I would recommend putting the volume-space mask into surface space, >> rather than trying to put the surface-based data back into volume space. >> There is less information to be lost in a binary mask than in timeseries >> data. >> >> As we have implied, defining a cortical ROI in MNI volume space is >> inherently defining it on a rather blurry map, as far as brain function is >> concerned, because MNI registration is (so far) based only on the shape of >> the brain, which is both quite variable across subjects over large expanses >> of cortex, and because function does not always line up with these brain >> shape features. >> >> However, it is possible to map such an ROI onto the surface, taking into >> account this blurriness, but it won't be binary anymore, and it will reveal >> what parts of cortex it is grabbing that you probably didn't want it to. >> To do so, you can take a large number (at a guess, 30+, more is better but >> takes longer) of randomly-chosen HCP subjects, and use wb_command >> -volume-to-surface-mapping with -ribbon-constrained and each subject's >> MNINonLinear pial and white surfaces. This will give you how your group >> ROI intersects each subject's cortical ribbon. Then, you can average this >> across subjects to see on average, what parts of subjects' cortex are being >> captured by your ROI. If you need it binary again, you will have to >> threshold it, and you might want to also use wb_command >> -metric-remove-islands (as your MNI space ROI will almost certainly cross >> to the opposite sulcal bank fairly strongly). >> >> Tim >> >> >> On Thu, Jul 19, 2018 at 6:25 AM, Aslan Satary Dizaji < >> [email protected]> wrote: >> >>> Thank you very much for both responses. Also, thank you for the >>> insightful paper. >>> >>> Here, I am going to describe a processing pipeline and I was wondering >>> if you could tell me if there is something wrong with this pipeline: >>> >>> 1) We read "rfMRI_REST{1,2}_{LR,RL}_Atlas_MSMAll_hp2000_clean.dtseries.nii" >>> with "ft_read_cifti.m" and "${subject}.{L,R}. >>> midthickness_MSMAll.32k_fs_LR.surf.gii" with "gifti.m" of each subject. >>> >>> 2) We save four fields of the generated structure by "ft_read_cifti.m": >>> 2-1) "dtseries" which contains the time-series of subcortical voxels >>> and cortical grayordinates. >>> 2-2) "pos" which, I assume, contains the MNI coordinates of >>> subcortical voxels. [?] >>> 2-3) "brainstructure" which labels each structure of brain with >>> different numbers. >>> 2-4) "transform" which, I assume, has the matrix for transformation >>> of coordinates from MNI-mm space to MNI-matrix space (91,109,91). [?] >>> >>> 3) We save only the "vertices" field of the generated structure by >>> "gifti.m" which, I assume, contains the coordinates of cortical >>> grayordinates for left or right hemisphere in the MNI-mm space. [?] >>> >>> 4) Let's assume further that we want to apply a particular 3D mask in >>> the MNI-matrix space (91,109,91). >>> >>> 5) By using "brainstructure" and "vertices", we can complete the "pos" >>> with the correct coordinates of cortical grayordinates. >>> >>> 6) By using "transform", we can transform the coordinates of "pos" from >>> the MNI-mm space to the MNI-matrix space (91,109,91). >>> >>> 7) Now we have a complete set of time-series from "dtseries" with their >>> corresponding coordinates in the MNI-matrix space (91,109,91). >>> >>> 8) At this stage, we can apply our mask to this data. >>> >>> Thank you in advance for your time and consideration. >>> >>> Best regards, >>> >>> Aslan >>> >>> On Thu, Jul 19, 2018 at 1:15 AM Timothy Coalson <[email protected]> wrote: >>> >>>> As an additional note, if you do use the non-MSMAll data, you should >>>> not use an MSMAll surface with it. The data and surface file should go >>>> through the same registration and resampling. The files without MSMAll in >>>> their names are registered/resampled using MSMSulc. >>>> >>>> Tim >>>> >>>> >>>> On Wed, Jul 18, 2018 at 8:16 AM, Glasser, Matthew <[email protected]> >>>> wrote: >>>> >>>>> 1. rfMRI_REST1_LR_Atlas_MSMAll_hp2000_clean.dtseries.nii >>>>> 2-3. 100307.L.midthickness_MSMAll.32k_fs_LR.surf.gii >>>>> >>>>> Note that the surface coordinates or only valid for single >>>>> individuals. There is no “standard space” (like MNI space) that properly >>>>> lines up the cortical areas, instead surface registration brings the data >>>>> onto a standard 32k mesh where vertex 1000 has the same neuroanatomical >>>>> location across subjects. You probably don’t actually need the surface >>>>> coordinates for your analysis unless you are doing something unusual. >>>>> >>>>> Peace, >>>>> >>>>> Matt. >>>>> >>>>> From: Aslan Satary Dizaji <[email protected]> >>>>> Date: Wednesday, July 18, 2018 at 12:57 AM >>>>> To: Matt Glasser <[email protected]> >>>>> Cc: "[email protected]" <[email protected]>, >>>>> Mohammad Reza Khodaei <[email protected]> >>>>> Subject: Re: [HCP-Users] The coordinates of surface time-series of >>>>> Resting State fMRI FIX-Denoised (Compact) >>>>> >>>>> Dear Matt, >>>>> >>>>> Thank you for your email. >>>>> >>>>> In "Resting State fMRI FIX-Denoised (Compact)" of 100 unrelated >>>>> subjects, inside folder "${StudyFolder}/${Subject}/MNINonLinear", >>>>> there is only one folder, "Results", which inside it there are four >>>>> folders >>>>> "rfMRI_REST1_LR", "rfMRI_REST1_RL", "rfMRI_REST2_LR", "rfMRI_REST2_RL". >>>>> And >>>>> finally inside each one of these folders, there are two "*.dtseries.nii" >>>>> files and two "*.dtscalar.nii" files. So basically, in "Resting State >>>>> fMRI FIX-Denoised (Compact)" of 100 unrelated subjects, there is not any >>>>> folder with the name of "fsaverage_LR32k". However, I checked the >>>>> other data-sets of 100 unrelated subjects, and I found that >>>>> "Structural Preprocessed" of 100 unrelated subjects has the >>>>> "fsaverage_LR32k" >>>>> folder with the files that you mentioned. So my question is that, do we >>>>> need to download this data-set too so to be able to get the coordinates of >>>>> surface time-series? >>>>> >>>>> Also, I have three other questions: >>>>> >>>>> 1) Which one of these "*.dtseries.nii" files do you recommend that we >>>>> use: >>>>> >>>>> rfMRI_REST1_LR_Atlas_hp2000_clean.dtseries.nii >>>>> rfMRI_REST1_LR_Atlas_MSMAll_hp2000_clean.dtseries.nii >>>>> >>>>> 2) For example, for subject 100307 and for left hemisphere, which one >>>>> of these three "*.surf.gii" files do you recommend that we use: >>>>> >>>>> 100307.L.inflated.32k_fs_LR.surf.gii >>>>> 100307.L.midthickness.32k_fs_LR.surf.gii >>>>> 100307.L.very_inflated.32k_fs_LR.surf.gii >>>>> >>>>> 3) I assume that with "rfMRI_REST1_LR_Atlas_hp2000_clean.dtseries.nii", >>>>> we should use one of the three above "*.surf.gii" files and with " >>>>> rfMRI_REST1_LR_Atlas_MSMAll_hp2000_clean.dtseries.nii", we should use >>>>> one of the three below "*.surf.gii" files: >>>>> >>>>> 100307.L.inflated_MSMAll.32k_fs_LR.surf.gii >>>>> 100307.L.midthickness_MSMAll.32k_fs_LR.surf.gii >>>>> 100307.L.very_inflated_MSMAll.32k_fs_LR.surf.gii >>>>> >>>>> Am I right? >>>>> >>>>> Many many thanks in advance for your time and consideration. >>>>> >>>>> Best regards, >>>>> >>>>> Aslan >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> HCP-Users mailing list >>>>> [email protected] >>>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>>>> >>>> >>>> >> _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
