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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: Inline replies. On Wed, Nov 18, 2015 at 8:47 AM, Matthew George Liptrot <[email protected]<mailto:[email protected]>> wrote: 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: • 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]<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]>> > 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]>> > 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]>> > 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]><mailto:[email protected]> > www.humanconnectome.org > > From: > [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]> > 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]><mailto:[email protected]> > > From: Vishal Patel > <[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]>" > <[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
