Re: [HCP-Users] Hcp Data with non-overlapping parcellations

[Harms, Michael]

If you are interested in using matlab, another possibility to consider is that the 'ciftiopen' matlab tool can load .dlabel.nii and .pconn.nii files (and thus I assume .dconn.nii files as well).  That will just give you the data values stored in each file type, but the indices in matlab will be in correspondence across all file types for a given CIFTI atlas. 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: mha...@wustl.edu From: Matthew George Liptrot <matthew.lipt...@di.ku.dk> Date: Wednesday, November 18, 2015 8:47 AM To: Timothy Coalson <tsc...@mst.edu>, Donna Dierker <do...@brainvis.wustl.edu> Cc: HCP Listserv <hcp-users@humanconnectome.org> Subject: Re: [HCP-Users] Hcp Data with non-overlapping parcellations Hi, Thanks both of you.  On 17/11/15 21:32 , "Timothy Coalson" <tsc...@mst.edu> 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: The CIFTI data-value:vertex mapping is not necessarily bijective (unique)?  The CIFTI data-value:vertex mapping is not necessarily complete (some vertices may not be represented)? 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 1010 29 2929 24 2424 28 2828 11 1111 31 3131 27 2727 0 -113 13 1315 15 1535 35 3535 35 3510 10 1010 10 1010 10 1010 10 1010 10 1010 10 1010 10 1010 10 1010 10 1010 0 1010 0 1010 0 1010 0 1010 0 1010 0 1010 0 -110 0 -110 0 -110 0 -110 0 -110 0 -110 0 -110 0 -110 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, <do...@brainvis.wustl.edu> 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" > <do...@brainvis.wustl.edu<mailto:do...@brainvis.wustl.edu>> 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 > <matthew.lipt...@di.ku.dk<mailto:matthew.lipt...@di.ku.dk>> 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" > <el...@pcg.wustl.edu<mailto:el...@pcg.wustl.edu>> 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 > el...@pcg.wustl.edu<mailto:el...@pcg.wustl.edu> > www.humanconnectome.org > > From: > hcp-users-boun...@humanconnectome.org<mailto:hcp-users-boun...@humanconnectome.org> > [mailto:hcp-users-boun...@humanconnectome.org] On Behalf Of Harms, > Michael > Sent: Wednesday, November 04, 2015 3:40 PM > To: Vishal Patel; > hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org> > 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: mha...@wustl.edu<mailto:mha...@wustl.edu> > > From: Vishal Patel <vpatel1...@gmail.com<mailto:vpatel1...@gmail.com>> > Date: Wednesday, November 4, 2015 1:42 PM > To: "hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org>" > <hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org>> > 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 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 _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users   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 HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users