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" <tsc...@mst.edu<mailto:tsc...@mst.edu>>
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
<tsc...@mst.edu<mailto:tsc...@mst.edu>> wrote:
Inline replies.
On Wed, Nov 18, 2015 at 8:47 AM, Matthew George Liptrot
<matthew.lipt...@di.ku.dk<mailto:matthew.lipt...@di.ku.dk>> wrote:
Hi,
Thanks both of you.
On 17/11/15 21:32 , "Timothy Coalson" <tsc...@mst.edu<mailto: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 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,
<do...@brainvis.wustl.edu<mailto: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><mailto: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><mailto: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><mailto: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<tel:314-362-9387>
> el...@pcg.wustl.edu<mailto:el...@pcg.wustl.edu><mailto:el...@pcg.wustl.edu<mailto:el...@pcg.wustl.edu>>
> www.humanconnectome.org<http://www.humanconnectome.org>
>
> From:
> hcp-users-boun...@humanconnectome.org<mailto:hcp-users-boun...@humanconnectome.org><mailto:hcp-users-boun...@humanconnectome.org<mailto: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><mailto: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<tel:314-747-6173>
> St. Louis, MO 63110 Email:
> mha...@wustl.edu<mailto:mha...@wustl.edu><mailto:mha...@wustl.edu<mailto:mha...@wustl.edu>>
>
> From: Vishal Patel
> <vpatel1...@gmail.com<mailto:vpatel1...@gmail.com><mailto: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><mailto:hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org>>"
> <hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org><mailto: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>
--
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
