Sorry, the -*-label-export-table commands don't put the unlabeled key in the text file. Use -file-information on them instead to check what key value the "???" label is (it means the unlabled value).
Tim On Wed, Nov 18, 2015 at 12:54 PM, Timothy Coalson <tsc...@mst.edu> wrote: > Inline replies. > > On Wed, Nov 18, 2015 at 8:47 AM, Matthew George Liptrot < > matthew.lipt...@di.ku.dk> wrote: > >> 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: >> >> 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, <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* >> >> <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 HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
