Hi, Thanks both of you.
On 17/11/15 21:32 , "Timothy Coalson" <[email protected]<mailto:[email protected]>> wrote: So, cifti is not a 1:1 mapping to surface vertices. If what you plan to use can read gifti, the less error-prone route is probably to use -cifti-separate to get a nifti volume and gifti files that do have a 1:1 mapping to vertices. @Tim: By “not a 1:1 mapping to surface vertices”, do you mean: 1. The CIFTI data-value:vertex mapping is not necessarily bijective (unique)? 2. The CIFTI data-value:vertex mapping is not necessarily complete (some vertices may not be represented)? 3. A combination of 1 & 2? I hope it’s (2), because otherwise I’m confused (again!). A follow-on question is then why would it be less error-prone to use -cifti–separate (as opposed to e.g. -cifti-export-dense-mapping)? I can see that using -cifti-export-dense-mapping on the Conn3.dconn.nii file lists a non-contiguous mapping of node-IDs:Vertex-Ids, presumably due to the omission of the vertices on medial wall that are covered by the subcortical ROIs, i.e. CortexLeft, Total entries: 29696 (Node IDs: 0-29695, Vertice IDs: 0-32491) CortexRight, Total entries: 29716 (Node IDs: 29696-59411, Vertice IDs: 0-32491) SubCortical, Total entries: 31870 (Node IDs: 59412-91281) Is this what you were referring to? I then tried using some of your suggestions to extract the labels from the aparc32k atlas in 100307/MNINonLinear/fsaverage_LR32k. I tried the following 3 workflows: (A) > wb_command -cifti-separate 100307.aparc.32k_fs_LR.dlabel.nii COLUMN -label > CORTEX_LEFT aparc32k_fs_LR_dlabel_Separated_CortexLeft.gii > wb_command -gifti-convert ASCII > aparc32k_fs_LR_dlabel_Separated_CortexLeft.gii > aparc32k_fs_LR_dlabel_Separated_GiftiConvert_CortexLeft.txt > cp aparc32k_fs_LR_dlabel_Separated_GiftiConvert_CortexLeft.txt > aparc32k_fs_LR_dlabel_Separated_GiftiConvert_CortexLeft_LabelsOnly.txt # Strip away all header/footer XML codes from aparc32k_fs_LR_dlabel_Separated_GiftiConvert_CortexLeft_LabelsOnly.txt using emacs > wc -l aparc32k_fs_LR_dlabel_Separated_GiftiConvert_CortexLeft_LabelsOnly.txt 32492 (B) > wb_command -gifti-convert ASCII 100307.L.aparc.32k_fs_LR.label.gii > L_aparc32k_fs_LR_label_GiftiConvert_CortexLeft.txt > cp L_aparc32k_fs_LR_label_GiftiConvert_CortexLeft.txt > L_aparc32k_fs_LR_label_GiftiConvert_CortexLeft_LabelsOnly.txt # Strip away all header/footer XML codes from L_aparc32k_fs_LR_label_GiftiConvert_CortexLeft_LabelsOnly.txt using emacs > wc -l L_aparc32k_fs_LR_label_GiftiConvert_CortexLeft_LabelsOnly.txt 32492 (C) > wb_command -cifti-convert -to-text 100307.aparc.32k_fs_LR.dlabel.nii > aparc32k_fs_LR_dlabel_ConvertedToText_NodeID_LabelOnly_CortexAll.txt > wc -l aparc32k_fs_LR_dlabel_ConvertedToText_NodeID_LabelOnly_CortexAll.txt 59412 As you can see, they all gave the expected number of outputs (the latter one with the medial wall vertices already removed) However, when I look at the first few labels, there are some differences between set (A) and (B): A B C 10 10 10 29 29 29 24 24 24 28 28 28 11 11 11 31 31 31 27 27 27 0 -1 13 13 13 15 15 15 35 35 35 35 35 35 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 0 10 10 0 10 10 0 10 10 0 10 10 0 10 10 0 10 10 0 -1 10 0 -1 10 0 -1 10 0 -1 10 0 -1 10 0 -1 10 0 -1 10 0 -1 10 Shouldn’t these two give the same? Or maybe this is the errors you were referring to? Thanks in advance, M@ Otherwise, have a look at -cifti-label-export-table, -cifti-convert -to-text (other options exist here for nifti-1 and gifti), and -cifti-export-dense-mapping in order to get text files that can get you to the vertex mapping. Tim On Tue, Nov 17, 2015 at 11:25 AM, <[email protected]<mailto:[email protected]>> wrote: Try this: wb_command -gifti-convert ASCII my.label.gii ascii.label.gii If needed, strip everything up to <Data>, and then the label values are listed in vertex sequence. Will need to think about the HOA question. Hmmm. Donna > Hi Donna, > > Many thanks for your thorough reply. I can see that I wasn’t very clear > on explaining what we are trying to achieve – I’ll try to clarify > things a little :-) > > What we have done so far: > Generated Conn3.dconn.nii files: 92K x 92K structural connectivity > matrices from the DWI data in FSL’s matrix3 format (WM seeds, cortical > surface & subcortical voxels as targets). > This provides us with connectivity matrices whose nodes are (to the limit > of the HCP registration pipeline) anatomically matched across subjects. > > What we are analyzing: > Machine-learning parcellation of these connectivity matrices. > > What we would like to do: > Compare our machine-learning parcellations with previously published / > commonly-used ones. > For this we would like to be able to obtain, for each atlas, a label per > node of the connectivity matrices. > For some atlases, e.g. Desikan-Killiany, I realise that these labels:node > mappings will vary per subject as the atlas is adapted according to the > individual’s gyrification patterns. > For other atlases though, e.g. the Gordon 2014 atlas, the label:node > mapping is fixed. > It would also be great if we could compare against some MNI-based > parcellation schemes, such as the Harvard-Oxford. (Other suggestions > welcome!) > > So to my questions! :-) > > 1) What is the best way to get the per-subject label:node mapping from the > existing *.dlabel.nii and *.label.gii files? > I was thinking of using something like: > > wb_command -file–information > 100307/MNINonLinear/fsaverage_LR32k/100307.aparc.a2009s.32k_fs_LR.dlabel.nii > > which gives me (with a bit of filtering) a parcel:label mapping. > Then using: > > wb_command -nifti-information -print-matrix > 100307/MNINonLinear/fsaverage_LR32k/100307.aparc.a2009s.32k_fs_LR.dlabel.nii > > to give me a vertex:parcel mapping. Then I need to stitch the two together > somehow. > Are these steps correct? Is there a better (easier) way? > > 2) Would I use the same method for the Gordon atlas (which I understand is > provided on the standard 32K mesh)? > > 3) How would I do this for, e.g. the Harvard-Oxford atlas? Should I map > the voxelwise parcels onto the 32K mesh first and then use the same method > as for (2)? > > I’m still a surface-space novice, but I hope this is a bit clearer now > :-) > > Many thanks for any help/advice! > > Cheers, > > M@ > > On 13/11/15 20:25 , "Donna Dierker" > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > wrote: > > Hi Matthew, > > The aparc files Jenn meant are generated by Freesurfer, but we make them > available in cifti (*dlabel.nii) and gifti (*.label.gii) formats: > > * 164k standard mesh > Structural_preproc/MNINonLinear/994273.aparc.164k_fs_LR.dlabel.nii > Structural_preproc/MNINonLinear/994273.aparc.a2009s.164k_fs_LR.dlabel.nii > Structural_preproc/MNINonLinear/994273.L.aparc.164k_fs_LR.label.gii > Structural_preproc/MNINonLinear/994273.L.aparc.a2009s.164k_fs_LR.label.gii > Structural_preproc/MNINonLinear/994273.R.aparc.164k_fs_LR.label.gii > Structural_preproc/MNINonLinear/994273.R.aparc.a2009s.164k_fs_LR.label.gii > * 32k standard mesh > Structural_preproc/MNINonLinear/fsaverage_LR32k/994273.aparc.32k_fs_LR.dlabel.nii > Structural_preproc/MNINonLinear/fsaverage_LR32k/994273.aparc.a2009s.32k_fs_LR.dlabel.nii > Structural_preproc/MNINonLinear/fsaverage_LR32k/994273.L.aparc.32k_fs_LR.label.gii > Structural_preproc/MNINonLinear/fsaverage_LR32k/994273.L.aparc.a2009s.32k_fs_LR.label.gii > Structural_preproc/MNINonLinear/fsaverage_LR32k/994273.R.aparc.32k_fs_LR.label.gii > Structural_preproc/MNINonLinear/fsaverage_LR32k/994273.R.aparc.a2009s.32k_fs_LR.label.gii > * native mesh > Structural_preproc/MNINonLinear/Native/994273.aparc.a2009s.native.dlabel.nii > Structural_preproc/MNINonLinear/Native/994273.aparc.native.dlabel.nii > Structural_preproc/MNINonLinear/Native/994273.L.aparc.a2009s.native.label.gii > Structural_preproc/MNINonLinear/Native/994273.L.aparc.native.label.gii > Structural_preproc/MNINonLinear/Native/994273.R.aparc.a2009s.native.label.gii > Structural_preproc/MNINonLinear/Native/994273.R.aparc.native.label.gii > > If you get the structural extended packages, you can get the original > Freesurfer subject directory (e.g. Structural_preproc/T1w/994273). > > Note these include not only the Desikan-Killiany (aparc), but also the > Destrieux (aparc.a2009s): > > https://surfer.nmr.mgh.harvard.edu/fswiki/CorticalParcellation > > The only relation these have to the Conte69 is that they are both > available in the 164k and 32k standard meshes. These are very nice > parcellations Freesurfer provides in normal processing; we just make them > available on different meshes/formats for the HCP subjects. > > I assume you are interested in anatomical parcellations only, and not > functional (e.g., > https://surfer.nmr.mgh.harvard.edu/fswiki/CorticalParcellation_Yeo2011). > I think you will see improved parcellations coming out soon, so stay > tuned. > > I am not a diffusion expert, so I don't have a good feel for what you are > trying to do, though it may involve identifying where tracts terminate and > seeing how often varying parcellations agree using the same tracts (???). > > Donna > > > On Nov 13, 2015, at 8:35 AM, Matthew George Liptrot > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > wrote: > > Hiya, > We would like to compare several parcellation schemes with the results of > structural connectivity on the HCP data (we have generated dense > connectome data for several subjects). > The Freesurfer parcellation (which is based upon the Conte69 atlas?) is > already provided on the 32K subject mesh, but we would like to compare > others, e.g. Desikan-Killiany, Harvard-Oxford, microstructure etc. In > short: > 1) What would be the optimal way to do this? > 2) Which wb_commands should we use? > 3) Which atlases would people recommend (we want to look at replication > performance across subjects) > 4) There seems to only be a small subset of Brodmann areas in the > distributed subjects’ 32K CIFTI files (mainly the visual cortex and > areas around pre- and post-central gyrus). Any reason why the rest are > missing? > Thanks in advance for any pointers! > Cheers, > M@ > On 4/11/15 23:17 , "Jennifer Elam" > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > wrote: > Hi Vishal, > Also, the FreeSurfer-generated aparc and aparc.a2009s non-overlapping > parcellations for each subject are available on the 32k_fs_LR mesh and > 164k mesh in the Structural preprocessed package for each subject. These > are available as GIFTI label files per hemisphere and as CIFTI dlabel > files (both hemispheres). > > Best, > Jenn > > Jennifer Elam, Ph.D. > Outreach Coordinator, Human Connectome Project > Washington University School of Medicine > Department of Anatomy and Neurobiology, Box 8108 > 660 South Euclid Avenue > St. Louis, MO 63110 > 314-362-9387<tel:314-362-9387> > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > www.humanconnectome.org<http://www.humanconnectome.org> > > From: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > [mailto:[email protected]<mailto:[email protected]>] > On Behalf Of Harms, > Michael > Sent: Wednesday, November 04, 2015 3:40 PM > To: Vishal Patel; > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > Subject: Re: [HCP-Users] Hcp Data with non-overlapping parcellations > > > Hi Vishal, > There is a version of the hard parcellation from Gordon et al. (Cerebral > Cortex, 2014) available as a CIFTI 'dlabel.nii' file, if you are > interested in that. > > cheers, > -MH > > -- > Michael Harms, Ph.D. > ----------------------------------------------------------- > Conte Center for the Neuroscience of Mental Disorders > Washington University School of Medicine > Department of Psychiatry, Box 8134 > 660 South Euclid Ave. Tel: 314-747-6173<tel:314-747-6173> > St. Louis, MO 63110 Email: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > > From: Vishal Patel > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > Date: Wednesday, November 4, 2015 1:42 PM > To: > "[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>" > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > Subject: [HCP-Users] Hcp Data with non-overlapping parcellations > > Hi, > > Does anyone have access to HCP data that has been parcellated in > non-overlapping regions or can point me in the right direction? > > Thanks, > > Vishal -- Matthew George Liptrot <http://about.me/matthewliptrot> Department of Computer Science University of Copenhagen & Section for Cognitive Systems Department of Applied Mathematics and Computer Science Technical University of Denmark http://about.me/matthewliptrot <http://about.me/matthewliptrot> _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
