Inline replies. On Wed, Nov 18, 2015 at 8:47 AM, Matthew George Liptrot < [email protected]> wrote:
> Hi, > > Thanks both of you. > > On 17/11/15 21:32 , "Timothy Coalson" <[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!). > Just (2), yes. Technically this also means it is not bijective, but the mapping of cifti index to vertex/voxel is injective (no two cifti indices represent the same vertex or voxel). > 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. > I called it less error-prone because it applies the cifti->vertex/voxel mapping for you, rather than making you figure out how to do it. > 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? > Yes. > 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) > (C) is obviously not going to match index for index, and the formatting of the below list got messed up, but... > 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 > I don't know why -1 is here, that is very unusual for a gifti label file. It looks like it is used as the unlabeled key, unlike the cifti version that uses 0 - try -cifti-label-export-table and -label-export-table on the two files and see if something shows up for -1, like the "???" key. 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]> 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]>> 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]>> 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]>> 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 >> > [email protected]<mailto:[email protected]> >> > www.humanconnectome.org >> > >> > From: >> > [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]> >> > 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 >> > St. Louis, MO 63110 Email: [email protected]<mailto:[email protected]> >> > >> > From: Vishal Patel <[email protected]<mailto:[email protected]>> >> > Date: Wednesday, November 4, 2015 1:42 PM >> > To: "[email protected]<mailto:[email protected] >> >" >> > <[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
