Hi Matthew, Invert these files:
https://github.com/Washington-University/Pipelines/blob/master/global/templates/standard_mesh_atlases/L.atlasroi.32k_fs_LR.shape.gii https://github.com/Washington-University/Pipelines/blob/master/global/templates/standard_mesh_atlases/R.atlasroi.32k_fs_LR.shape.gii Those files have 1's outside the medial wall, 0's inside the medial wall. Donna On 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]>> 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 > > 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 [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
