So, first, gifti files don't have any concept of "missing" vertices - they have a value for every vertex, period, no exceptions. Cifti files, however, don't store values that are outisde an ROI used when creating the dense mapping. If you masked the .label.gii files by this ROI, they would probably agree. Part of the issue with the matching is that the original aparc file is subject-specific, but in order to do cross-subject things, we need to use the same medial wall ROI for every subject (see the minimal preprocessing pipelines paper for details), so that we can do things like indexwise math and get something sensible.
As a more general way to get the ROI used in creating the dense mapping of a file (in practice, this is almost always the inverse of a medial wall ROI), use -cifti-separate with the -roi suboption of the -metric or -label options, as appropriate to the file type. You can also use -cifti-export-dense-mapping to get them as text files, describing what cifti indices correspond to what vertices (Cifti doesn't actually require that the vertices be in ascending order, but in practice this is likely to always be the case). Tim On Tue, Dec 15, 2015 at 8:56 AM, Matthew George Liptrot < [email protected]> wrote: > Hi Donna, Tim, et al, > > Thanks for the info. I’m now back to working on this issue again, and am > puzzled as to why this is occurring. Shouldn’t the two files: > > 100307.aparc.32k_fs_LR.dlabel.nii > 100307.L.aparc.32k_fs_LR.label.gii > > generate the same ‘absent’ vertices for the medial wall? And why are they > different from the ‘standard' HCP medial wall? > > After generating the look-up tables from these files, I naturally end-up > with 32,492 entries per hemisphere, though with varying numbers of nulls > (‘0’ or ‘-1’ depending upon the conversion, hemisphere and subject). The > structural connectivity matrices we have generated from the diffusion data > (and based upon the HCP ‘Tractography' pipeline scripts) are all size 91282 > x 91282, incorporating 29696 vertices for Cortex Left, then 29716 vertices > for Cortex Right, and finally 31870 subcortical voxels. > > So now I need to remove the same set of "standard HCP medial wall" > vertices from the ‘full’ 32,492 vertices per hemisphere, so that I am left > with only those vertices that match the ones in the connectivity matrix. > > Hence my next question is where can I obtain the "standard HCP medial > wall” mask that was used to generate the connectivity matrices? I guess > that it comes from the Conte69 atlas somehow? > > Cheers, > > M@ > > On 19/11/15 18:10 , "Donna Dierker" <[email protected]> wrote: > > Hi Matthew, > > I was able to replicate what you are seeing. The label.gii is encoding > the medial wall as -1, while the dlabel.nii is encoding it as 0. The more > substantive differences are due to the fact that the dlabel.nii has a more > generous medial wall than the label.gii files do: > > http://brainmap.wustl.edu/pub/donna/WUSTL/HCP/Misc/ > login pub > password download > > I would not have expected this. I vote for the dlabel.nii route. > > Donna > > > On Nov 19, 2015, at 3:13 AM, Matthew George Liptrot < > [email protected]> wrote: > > Hi again, > The -file–information on the files generated with method (A) and (B) below > give the same key value for “???”: > # (A) (Changed output of first line to include *.label.*, otherwise the > -file–information command does not recognise the file format correctly.) > > wb_command -cifti-separate 100307.aparc.32k_fs_LR.dlabel.nii COLUMN > -label CORTEX_LEFT aparc32k_fs_LR_dlabel_Separated_CortexLeft.label.gii > > wb_command -gifti-convert ASCII > aparc32k_fs_LR_dlabel_Separated_CortexLeft.label.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 > # (A) > > wb_command -file-information > aparc32k_fs_LR_dlabel_Separated_CortexLeft.label.gii > Name: > aparc32k_fs_LR_dlabel_Separated_CortexLeft.label.gii > Type: Label > Structure: CortexLeft > Data Size: 129.97 Kilobytes > Maps to Surface: true > Maps to Volume: false > Maps with LabelTable: true > Maps with Palette: false > Number of Maps: 1 > Number of Vertices: 32492 > Map Map Name > 1 100307_aparc > Label table for ALL maps > KEY NAME RED GREEN BLUE ALPHA > 0 ??? 0.000 0.000 0.000 0.000 > 1 L_bankssts 0.098 0.392 0.157 1.000 > 2 L_caudalanteriorcingulate 0.490 0.392 0.627 1.000 > 3 L_caudalmiddlefrontal 0.392 0.098 0.000 1.000 > 4 L_corpuscallosum 0.471 0.275 0.196 1.000 > 5 L_cuneus 0.863 0.078 0.392 1.000 > ... > # (B) > > wb_command -file-information 100307.L.aparc.32k_fs_LR.label.gii > Name: 100307.L.aparc.32k_fs_LR.label.gii > Type: Label > Structure: CortexLeft > Data Size: 129.97 Kilobytes > Maps to Surface: true > Maps to Volume: false > Maps with LabelTable: true > Maps with Palette: false > Number of Maps: 1 > Number of Vertices: 32492 > Map Map Name > 1 100307_L_aparc > Label table for ALL maps > KEY NAME RED GREEN BLUE ALPHA > 0 ??? 0.000 0.000 0.000 0.000 > 1 L_bankssts 0.098 0.392 0.157 1.000 > 2 L_caudalanteriorcingulate 0.490 0.392 0.627 1.000 > 3 L_caudalmiddlefrontal 0.392 0.098 0.000 1.000 > 4 L_corpuscallosum 0.471 0.275 0.196 1.000 > 5 L_cuneus 0.863 0.078 0.392 1.000 > ... > However, what I’m more concerned about is not so much the labels for > Key=0, but that some of the other vertices have different labels – see > lines 22-27 below: > A B > 10 10 > 29 29 > 24 24 > 28 28 > 11 11 > 31 31 > 27 27 > 0 -1 > 13 13 > 15 15 > 35 35 > 35 35 > 10 10 > 10 10 > 10 10 > 10 10 > 10 10 > 10 10 > 10 10 > 10 10 > 10 10 > 0 10 > 0 10 > 0 10 > 0 10 > 0 10 > 0 10 > 0 -1 > 0 -1 > 0 -1 > 0 -1 > 0 -1 > 0 -1 > 0 -1 > 0 -1 > … > This is just the first few lines, and there are many more differences > throughout the files. Is this simply a vertex-ordering issue, or is there a > conversion error? > (Key 10 is “L_isthmuscingulate” in both). > Cheers, > M@ > On 18/11/15 22:14 , "Timothy Coalson" <[email protected]> wrote: > 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 <[email protected]> wrote: > 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: > • 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!). > 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 1010 > 29 2929 > 24 2424 > 28 2828 > 11 1111 > 31 3131 > 27 2727 > 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 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, <[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]> > <[email protected]%3E>> 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]> > <[email protected]%3E>> 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]> > <[email protected]%3E>> 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] <[email protected]>> > > www.humanconnectome.org > > > > From: > > [email protected]< > mailto:[email protected] > <[email protected]>> > > [mailto:[email protected] > <[email protected]>] On Behalf Of Harms, > > Michael > > Sent: Wednesday, November 04, 2015 3:40 PM > > To: Vishal Patel; > > [email protected]<mailto:[email protected] > <[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] > <[email protected]>> > > > > From: Vishal Patel <[email protected]<mailto:[email protected]> > <[email protected]%3E>> > > Date: Wednesday, November 4, 2015 1:42 PM > > To: "[email protected]<mailto:[email protected]> > <[email protected]%3E>" > > <[email protected]<mailto:[email protected]> > <[email protected]%3E>> > > 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
