Re: [HCP-Users] MRI parameters

[Glasser, Matthew]

I don’t know anything about FreeSurfer’s tools for this.  If your FLIRT 
registration is precise, you can use something like this to map the data from 
the volume to the surface:

LeftGreyRibbonValue="3"
RightGreyRibbonValue="42"
MyelinMappingFWHM="5"
MyelinMappingSigma=`echo “${MyelinMappingFWHM} / ( 2 * ( sqrt ( 2 * l ( 2 ) ) ) 
)" | bc -l`

for Hemisphere in L R ; do
  if [ $Hemisphere = "L" ] ; then
Structure="CORTEX_LEFT"
ribbon=“${LeftGreyRibbonValue}"
  elif [ $Hemisphere = "R" ] ; then
Structure="CORTEX_RIGHT"
ribbon=“${RightGreyRibbonValue}"
  Fi

${CARET7DIR}/wb_command -volume-math "(ribbon > ($ribbon - 0.01)) * (ribbon < 
($ribbon + 0.01))" ${StudyFolder}/${Subject}/T1w/temp_ribbon.nii.gz -var ribbon 
${StudyFolder}/${Subject}/T1w/ribbon.nii.gz
${CARET7DIR}/wb_command -volume-to-surface-mapping  
${StudyFolder}/${Subject}/T1w/Native/${Subject}.${Hemisphere}.midthickness.native.surf.gii
 
${StudyFolder}/${Subject}/MNINonLinear/Native/${Subject}.${Hemisphere}.MyelinMap.native.func.gii
 -myelin-style ${StudyFolder}/${Subject}/T1w/temp_ribbon.nii.gz 
${StudyFolder}/${Subject}/MNINonLinear/Native/${Subject}.${Hemisphere}.thickness.native.shape.gii
 ${MyelinMappingSigma}

Peace,

Matt.

From: 
mailto:hcp-users-boun...@humanconnectome.org>>
 on behalf of Barbara Kreilkamp 
mailto:bakk@googlemail.com>>
Date: Tuesday, December 15, 2015 at 11:13 AM
To: Gaurav Patel mailto:gauravpa...@gmail.com>>
Cc: Rachel Woodall 
mailto:rachel.wood...@york.ac.uk>>, 
"hcp-users@humanconnectome.org" 
mailto:hcp-users@humanconnectome.org>>
Subject: Re: [HCP-Users] MRI parameters

Dear all,

I've acquired the T1w and T2w images on the GE scanner, additionally, as 
advised we've acquired a B1 field map.
I've been trying to use the HCP tools for volume to surface registration of the 
B1 map, but so far have had no success. I found an mri_vol2surf co-registration 
algorithm used within recon-all that I wanted to adapt (found no related 
commands in the PostFreesurferPipelineBatch.sh or SetUpHCPPipeline.sh), but it 
does not seem to work.

I wonder if you could please help out?
This is what I tried:

flirt -in REF066p_FieldMap.nii.gz -ref T1w/T1w_acpc_dc_restore.nii.gz -dof 6 
-out REF066p_FieldMap_coreg.nii.gz


mri_convert -rt nearest -rl T1w/T1w_acpc_dc_restore.nii.gz 
REF066p_FieldMap_coreg.nii.gz REF066p_FieldMap_coreg_resliced.nii.gz


mri_vol2surf --mov REF066p_FieldMap_coreg_resliced.nii.gz --hemi lh --noreshape 
--interp trilinear --o REF066p_FieldMap_coreg_resliced.lh.mgz --projfrac 0.3 
--regheader REF066p --cortex


mri_vol2surf --mov REF066p_FieldMap_coreg_resliced.nii.gz --hemi rh --noreshape 
--interp trilinear --o REF066p_FieldMap_coreg_resliced.rh.mgh --projfrac 0.3 
--regheader REF066p --cortex



Thank you very much,

Best wishes,

Barbara

On Tue, Dec 1, 2015 at 4:29 PM, Gaurav Patel 
mailto:gauravpa...@gmail.com>> wrote:
Just a warning from another GE user, we have not been able to replicate the 
myelin maps in Glasser/Van Essen with standard GE sequences on our MR750 (see 
previous threads on this forum about that).  If you do have success we'd love 
to know how.  We now have approval to run a GE prototype of the MPRAGE on our 
scanner, so hopefully soon we'll see if that solves the problem.

__
  gaurav patel
  gauravpa...@gmail.com
  www.neurofreak.net




On Nov 27, 2015, at 1:15 PM, Harms, Michael wrote:

>
> Please cc the list, so that others can respond and benefit from the exchange.
>
> No, we don't have an issue with TR/TE changing between our structural scans 
> on Siemens scanners.  Is there perhaps a mode of operation of a GE scanner 
> that overrides that sort of behavior, so that it keeps TR/TE completely 
> constant?  If you're operating the scanner in a regime where RF deposition is 
> near its limit, you might have to intentionally "back off" to derive a set of 
> parameters that will basically work for all subjects.
>
> 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
>
> From: Rachel Woodall 
> mailto:rachel.wood...@york.ac.uk>>
> Date: Thursday, November 26, 2015 6:00 AM
> To: "Harms, Michael" mailto:mha...@wustl.edu>>
> Subject: Re: [HCP-Users] MRI parameters
>
> Hi Michael,
>
> Apologies, I probably did not make myself very clear.
>
> I set up my scan protocol, assuming that the parameters I used would be fixed 
> and the same for every scan.  However, upon checking the DICOM information 
> after the scan, the TR and TE have differed from what was input.
>
> I have asked my radiographer whether this would be expected and he said that 
> the diff

Re: [HCP-Users] ROI parcellation

[Glasser, Matthew]

We’ll have a multi-modally based parcellation for the MSMAll CIFTI data soon.

Peace,

Matt.

From: 
mailto:hcp-users-boun...@humanconnectome.org>>
 on behalf of Jennifer Elam mailto:el...@pcg.wustl.edu>>
Date: Tuesday, December 15, 2015 at 3:51 PM
To: 'Joelle Zimmermann' 
mailto:joelle.t.zimmerm...@gmail.com>>, "Harms, 
Michael" mailto:mha...@wustl.edu>>
Cc: 'Greg Burgess' mailto:gcburg...@gmail.com>>, 
"hcp-users@humanconnectome.org" 
mailto:hcp-users@humanconnectome.org>>
Subject: Re: [HCP-Users] ROI parcellation

We have not distributed the Gordon et al. parcellation in any of the released 
HCP data yet. There are CIFTI surface-based parcellations available in both the 
Group Average and Connectome Workbench datasets available on the HCP project 
page in ConnectomeDB: https://db.humanconnectome.org/data/projects/HCP_900 as 
maps in the RSN-networks.32k_fs_LR.dlabel.nii file – the 7 and 17 RSN network 
parcellation from Yeo et al., JNP 2011 and the RSN network communities from 
Power et al., Neuron 2011.

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
www.humanconnectome.org

From: 
hcp-users-boun...@humanconnectome.org
 [mailto:hcp-users-boun...@humanconnectome.org] On Behalf Of Joelle Zimmermann
Sent: Tuesday, December 15, 2015 2:42 PM
To: Harms, Michael
Cc: Greg Burgess; 
hcp-users@humanconnectome.org
Subject: Re: [HCP-Users] ROI parcellation

Thank you Michael, I found those aparc+asegs there.

Is the Gordon et al. parcellation available in the package?

Greg, I'm aware of the advantages of the functional parcellation, it's sort of 
a test run I'm starting off with the anatomical parcellations. Thanks for the 
refs.

Joelle

On Tue, Dec 15, 2015 at 1:02 PM, Harms, Michael 
mailto:mha...@wustl.edu>> wrote:

Also, we encourage you to work in CIFTI-land so as to have a surface-based 
analysis of the cortical data.  But to answer your question, volumetric 
versions of both those FS parcellations are available in each subject's 
MNINonLinear folder; e.g.,
100307/MNINonLinear/aparc+aseg.nii.gz
100307/MNINonLinear/aparc.a2009s+aseg.nii.gz

Those particular files should be part of the standard Structural package.

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



On 12/15/15 11:51 AM, "Greg Burgess" 
mailto:gcburg...@gmail.com>> wrote:

Hi Joelle,

You should be aware of potential issues with using anatomically-defined ROIs 
for rfMRI network analysis.

Smith, S. M., Miller, K. L., Salimi-Khorshidi, G., Webster, M., Beckmann, C. 
F., Nichols, T. E., et al. (2011). Network modelling methods for FMRI. 
NeuroImage, 54(2), 875–891. http://doi.org/10.1016/j.neuroimage.2010.08.063

Gordon, E. M., Laumann, T. O., Adeyemo, B., Huckins, J. F., Kelley, W. M., & 
Petersen, S. E. (2014). Generation and Evaluation of a Cortical Area 
Parcellation from Resting-State Correlations. Cerebral Cortex. 
http://doi.org/10.1093/cercor/bhu239

--Greg


Greg Burgess, Ph.D.
Staff Scientist, Human Connectome Project
Washington University School of Medicine
Department of Neuroscience
Phone: 314-362-7864
Email: gburg...@wustl.edu

On Dec 15, 2015, at 11:24 AM, Joelle Zimmermann 
mailto:joelle.t.zimmerm...@gmail.com>> wrote:
Hi Michael,
Thanks! So currently, the 2 available parcellation schemes are the Freesurfer 
Desikan-Killiany (aparc+aseg.mgz) and Destrieux (aparc.a2009s+aseg.mgz) in the 
structural extended preprocessed/T1w/mri folder? Im presuming these are in the 
subject's T1 individual subject space.
Are you aware whether these parcellation schemes are already available in the 
MNI standard space? The goal is to parcellate the functional BOLD data (which 
are currently in MNI standard space; Ie in the FIX extended package, the 
MNINonLinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_hp2000_clean.nii). Or 
alternatively, if you could point me to where the volumetric functional BOLD 
data in T1 space is (I cannot locate it in the FIX extended package - this only 
seems to have func already normalized to MNI), I could directly apply the 
aparc+aseg parcellation (that's in T1 space) to this.
Thanks,
Joelle
On Tue, Dec 15, 2015 at 10:46 AM, Harms, Michael 
mailto:mha...@wustl.edu>> wrote:
Hi,
The only purely anatomical parcellation that is available currently are those 
provided by 

Re: [HCP-Users] ROI parcellation

[Jennifer Elam]

We have not distributed the Gordon et al. parcellation in any of the released 
HCP data yet. There are CIFTI surface-based parcellations available in both the 
Group Average and Connectome Workbench datasets available on the HCP project 
page in ConnectomeDB: https://db.humanconnectome.org/data/projects/HCP_900 as 
maps in the RSN-networks.32k_fs_LR.dlabel.nii file – the 7 and 17 RSN network 
parcellation from Yeo et al., JNP 2011 and the RSN network communities from 
Power et al., Neuron 2011.

 

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
www.humanconnectome.org

 

From: hcp-users-boun...@humanconnectome.org 
[mailto:hcp-users-boun...@humanconnectome.org] On Behalf Of Joelle Zimmermann
Sent: Tuesday, December 15, 2015 2:42 PM
To: Harms, Michael
Cc: Greg Burgess; hcp-users@humanconnectome.org
Subject: Re: [HCP-Users] ROI parcellation

 

Thank you Michael, I found those aparc+asegs there. 

 

Is the Gordon et al. parcellation available in the package? 

 

Greg, I'm aware of the advantages of the functional parcellation, it's sort of 
a test run I'm starting off with the anatomical parcellations. Thanks for the 
refs.

 

Joelle

 

On Tue, Dec 15, 2015 at 1:02 PM, Harms, Michael  wrote:

 

Also, we encourage you to work in CIFTI-land so as to have a surface-based 
analysis of the cortical data.  But to answer your question, volumetric 
versions of both those FS parcellations are available in each subject's 
MNINonLinear folder; e.g., 

100307/MNINonLinear/aparc+aseg.nii.gz

100307/MNINonLinear/aparc.a2009s+aseg.nii.gz

 

Those particular files should be part of the standard Structural package.

 

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

 

 

 

On 12/15/15 11:51 AM, "Greg Burgess"  wrote:

 

Hi Joelle,

 

You should be aware of potential issues with using anatomically-defined ROIs 
for rfMRI network analysis.

 

Smith, S. M., Miller, K. L., Salimi-Khorshidi, G., Webster, M., Beckmann, C. 
F., Nichols, T. E., et al. (2011). Network modelling methods for FMRI. 
NeuroImage, 54(2), 875–891. http://doi.org/10.1016/j.neuroimage.2010.08.063

 

Gordon, E. M., Laumann, T. O., Adeyemo, B., Huckins, J. F., Kelley, W. M., & 
Petersen, S. E. (2014). Generation and Evaluation of a Cortical Area 
Parcellation from Resting-State Correlations. Cerebral Cortex. 
http://doi.org/10.1093/cercor/bhu239

 

--Greg

 



Greg Burgess, Ph.D.

Staff Scientist, Human Connectome Project

Washington University School of Medicine

Department of Neuroscience

Phone: 314-362-7864

Email: gburg...@wustl.edu

 

On Dec 15, 2015, at 11:24 AM, Joelle Zimmermann  
wrote:

Hi Michael,

Thanks! So currently, the 2 available parcellation schemes are the Freesurfer 
Desikan-Killiany (aparc+aseg.mgz) and Destrieux (aparc.a2009s+aseg.mgz) in the 
structural extended preprocessed/T1w/mri folder? Im presuming these are in the 
subject's T1 individual subject space. 

Are you aware whether these parcellation schemes are already available in the 
MNI standard space? The goal is to parcellate the functional BOLD data (which 
are currently in MNI standard space; Ie in the FIX extended package, the 
MNINonLinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_hp2000_clean.nii). Or 
alternatively, if you could point me to where the volumetric functional BOLD 
data in T1 space is (I cannot locate it in the FIX extended package - this only 
seems to have func already normalized to MNI), I could directly apply the 
aparc+aseg parcellation (that's in T1 space) to this. 

Thanks,

Joelle

On Tue, Dec 15, 2015 at 10:46 AM, Harms, Michael  wrote:

Hi,

The only purely anatomical parcellation that is available currently are those 
provided by FreeSurfer, which you seem to be familiar with.

If you are interested in a functional parcellation, there is the Gordon et al. 
parcellation derived from non-HCP rfMRI data.  A parcellation that incorporates 
the myelin maps and rfMRI data and which is specifically derived from a subset 
of HCP participants is in the works (from Matt G.)

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

From: Joelle Zimmermann 

Date: Tuesday, December 15, 2015 9:35 AM

To: "hcp-users@humanconnectome.org" 

Subject

[HCP-Users] How to choose the parameters

[Mahmoud]

Dear experts,

Could someone please answer my questions below;

1- How the CorrectionSigma (sqrt 200) value was selected in
PostFreeSurferPipeline.sh ?

2- How about the values for  Sigma="5" , VARIABLESIGMA="4" in
FreeSurferHiresPial.sh for ?

I know I can easily change those values and maybe see the effect of them
but wanted to do it with some prior knowledge.

Thank you,
Mahmoud

___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Re: [HCP-Users] Hcp Data with non-overlapping parcellations

[Timothy Coalson]

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 <
matthew.lipt...@di.ku.dk> 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"  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 <
> matthew.lipt...@di.ku.dk> 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 

Re: [HCP-Users] ROI parcellation

[Joelle Zimmermann]

Thank you Michael, I found those aparc+asegs there.

Is the Gordon et al. parcellation available in the package?

Greg, I'm aware of the advantages of the functional parcellation, it's sort
of a test run I'm starting off with the anatomical parcellations. Thanks
for the refs.

Joelle

On Tue, Dec 15, 2015 at 1:02 PM, Harms, Michael  wrote:

>
> Also, we encourage you to work in CIFTI-land so as to have a surface-based
> analysis of the cortical data.  But to answer your question, volumetric
> versions of both those FS parcellations are available in each subject's
> MNINonLinear folder; e.g.,
> 100307/MNINonLinear/aparc+aseg.nii.gz
> 100307/MNINonLinear/aparc.a2009s+aseg.nii.gz
>
> Those particular files should be part of the standard Structural package.
>
> 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
>
>
>
> On 12/15/15 11:51 AM, "Greg Burgess"  wrote:
>
> Hi Joelle,
>
> You should be aware of potential issues with using anatomically-defined
> ROIs for rfMRI network analysis.
>
> Smith, S. M., Miller, K. L., Salimi-Khorshidi, G., Webster, M., Beckmann,
> C. F., Nichols, T. E., et al. (2011). Network modelling methods for FMRI.
> NeuroImage, 54(2), 875–891.
> http://doi.org/10.1016/j.neuroimage.2010.08.063
>
> Gordon, E. M., Laumann, T. O., Adeyemo, B., Huckins, J. F., Kelley, W. M.,
> & Petersen, S. E. (2014). Generation and Evaluation of a Cortical Area
> Parcellation from Resting-State Correlations. Cerebral Cortex.
> http://doi.org/10.1093/cercor/bhu239
>
> --Greg
>
> 
> Greg Burgess, Ph.D.
> Staff Scientist, Human Connectome Project
> Washington University School of Medicine
> Department of Neuroscience
> Phone: 314-362-7864
> Email: gburg...@wustl.edu
>
> On Dec 15, 2015, at 11:24 AM, Joelle Zimmermann <
> joelle.t.zimmerm...@gmail.com> wrote:
> Hi Michael,
> Thanks! So currently, the 2 available parcellation schemes are the
> Freesurfer Desikan-Killiany (aparc+aseg.mgz) and Destrieux
> (aparc.a2009s+aseg.mgz) in the structural extended preprocessed/T1w/mri
> folder? Im presuming these are in the subject's T1 individual subject
> space.
> Are you aware whether these parcellation schemes are already available in
> the MNI standard space? The goal is to parcellate the functional BOLD data
> (which are currently in MNI standard space; Ie in the FIX extended package,
> the MNINonLinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_hp2000_clean.nii).
> Or alternatively, if you could point me to where the volumetric functional
> BOLD data in T1 space is (I cannot locate it in the FIX extended package -
> this only seems to have func already normalized to MNI), I could directly
> apply the aparc+aseg parcellation (that's in T1 space) to this.
> Thanks,
> Joelle
> On Tue, Dec 15, 2015 at 10:46 AM, Harms, Michael  wrote:
> Hi,
> The only purely anatomical parcellation that is available currently are
> those provided by FreeSurfer, which you seem to be familiar with.
> If you are interested in a functional parcellation, there is the Gordon et
> al. parcellation derived from non-HCP rfMRI data.  A parcellation that
> incorporates the myelin maps and rfMRI data and which is specifically
> derived from a subset of HCP participants is in the works (from Matt G.)
> 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
> From: Joelle Zimmermann 
> Date: Tuesday, December 15, 2015 9:35 AM
> To: "hcp-users@humanconnectome.org" 
> Subject: [HCP-Users] ROI parcellation
> Hi everyone,
> Does HCP have a specific ROI parcellation that is commonly
> used/recommended? I  would prefer to begin with anatomically (rather than
> functionally defined) ROIs.
> My goal is to parcellate the voxel-wise time series into larger ROIs. I've
> previously used the Desikan-Killiany atlas, but ideally would be interested
> in using something with a finer parcellation.
> The only HCP parcellation I was able to find was the parcellation from the
> ICA decomposition (resulting in one timeseries per ICA component), with 25,
> 50, 100, 200, 300 components. However, I don't think this is something I am
> interested in, as a single node (ie component) may comprise voxels that are
> scattered across the brain.
> Is there anything like an anatomical ROI parcellation that's typically
> used by HCP people?
> Thanks,
> Joelle
> ___
> HCP-Users mailing list
> HCP-Users@humanconnectome.org
> http:

Re: [HCP-Users] Hcp Data with non-overlapping parcellations

[Donna Dierker]

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  
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"  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 
>  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   GREENBLUE   ALPHA  
>   0   ???  0.000   0.000   0.000   0.000  
>   1   L_bankssts   0.098   0.392   0.157   1.000  
>   2   L_caudalanteriorcingulate0.490   0.392   0.627   1.000  
>   3   L_caudalmiddlefrontal0.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:

Re: [HCP-Users] ROI parcellation

[Harms, Michael]

Also, we encourage you to work in CIFTI-land so as to have a surface-based analysis of the cortical data.  But to answer your question, volumetric versions of both those FS parcellations
 are available in each subject's MNINonLinear folder; e.g., 
100307/MNINonLinear/aparc+aseg.nii.gz

100307/MNINonLinear/aparc.a2009s+aseg.nii.gz


Those particular files should be part of the standard Structural package.


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







On 12/15/15 11:51 AM, "Greg Burgess"  wrote:


Hi Joelle,


You should be aware of potential issues with using anatomically-defined ROIs for rfMRI network analysis.


Smith, S. M., Miller, K. L., Salimi-Khorshidi, G., Webster, M., Beckmann, C. F., Nichols, T. E., et al. (2011). Network modelling methods for FMRI. NeuroImage, 54(2), 875–891.
http://doi.org/10.1016/j.neuroimage.2010.08.063


Gordon, E. M., Laumann, T. O., Adeyemo, B., Huckins, J. F., Kelley, W. M., & Petersen, S. E. (2014). Generation and Evaluation of a Cortical Area Parcellation from Resting-State Correlations. Cerebral
 Cortex. http://doi.org/10.1093/cercor/bhu239


--Greg



Greg Burgess, Ph.D.
Staff Scientist, Human Connectome Project
Washington University School of Medicine
Department of Neuroscience
Phone: 314-362-7864
Email: 
gburg...@wustl.edu



On Dec 15, 2015, at 11:24 AM, Joelle Zimmermann  wrote:

Hi Michael,

Thanks! So currently, the 2 available parcellation schemes are the Freesurfer Desikan-Killiany (aparc+aseg.mgz) and Destrieux (aparc.a2009s+aseg.mgz) in the structural extended preprocessed/T1w/mri folder? Im presuming these are in the subject's T1 individual
 subject space. 

Are you aware whether these parcellation schemes are already available in the MNI standard space? The goal is to parcellate the functional BOLD data (which are currently in MNI standard space; Ie in the FIX extended package, the MNINonLinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_hp2000_clean.nii).
 Or alternatively, if you could point me to where the volumetric functional BOLD data in T1 space is (I cannot locate it in the FIX extended package - this only seems to have func already normalized to MNI), I could directly apply the aparc+aseg parcellation
 (that's in T1 space) to this. 

Thanks,
Joelle



On Tue, Dec 15, 2015 at 10:46 AM, Harms, Michael  wrote:

Hi,
The only purely anatomical parcellation that is available currently are those provided by FreeSurfer, which you seem to be familiar with.

If you are interested in a functional parcellation, there is the Gordon et al. parcellation derived from non-HCP rfMRI data.  A parcellation that incorporates the myelin maps and rfMRI data and which is specifically derived from a subset of HCP participants
 is in the works (from Matt G.)

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

From: Joelle Zimmermann 
Date: Tuesday, December 15, 2015 9:35 AM
To: "hcp-users@humanconnectome.org" 
Subject: [HCP-Users] ROI parcellation

Hi everyone,

Does HCP have a specific ROI parcellation that is commonly used/recommended? I  would prefer to begin with anatomically (rather than functionally defined) ROIs.

My goal is to parcellate the voxel-wise time series into larger ROIs. I've previously used the Desikan-Killiany atlas, but ideally would be interested in using something with a finer parcellation.


The only HCP parcellation I was able to find was the parcellation from the ICA decomposition (resulting in one timeseries per ICA component), with 25, 50, 100, 200, 300 components. However, I don't think this is something I am interested in, as a single
 node (ie component) may comprise voxels that are scattered across the brain.

Is there anything like an anatomical ROI parcellation that's typically used by HCP people?

Thanks,
Joelle


___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users


  

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any
 action in reliance on the contents of this information is strictly prohibited. I

Re: [HCP-Users] ROI parcellation

[Joelle Zimmermann]

Hi Michael,

Thanks! So currently, the 2 available parcellation schemes are the
Freesurfer Desikan-Killiany (aparc+aseg.mgz) and Destrieux
(aparc.a2009s+aseg.mgz) in the structural extended preprocessed/T1w/mri
folder? Im presuming these are in the subject's T1 individual subject
space.

Are you aware whether these parcellation schemes are already available in
the MNI standard space? The goal is to parcellate the functional BOLD data
(which are currently in MNI standard space; Ie in the FIX extended package,
the MNINonLinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_hp2000_clean.nii).
Or alternatively, if you could point me to where the volumetric functional
BOLD data in T1 space is (I cannot locate it in the FIX extended package -
this only seems to have func already normalized to MNI), I could directly
apply the aparc+aseg parcellation (that's in T1 space) to this.

Thanks,
Joelle



On Tue, Dec 15, 2015 at 10:46 AM, Harms, Michael  wrote:

>
> Hi,
> The only purely anatomical parcellation that is available currently are
> those provided by FreeSurfer, which you seem to be familiar with.
>
> If you are interested in a functional parcellation, there is the Gordon et
> al. parcellation derived from non-HCP rfMRI data.  A parcellation that
> incorporates the myelin maps and rfMRI data and which is specifically
> derived from a subset of HCP participants is in the works (from Matt G.)
>
> 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
>
> From: Joelle Zimmermann 
> Date: Tuesday, December 15, 2015 9:35 AM
> To: "hcp-users@humanconnectome.org" 
> Subject: [HCP-Users] ROI parcellation
>
> Hi everyone,
>
> Does HCP have a specific ROI parcellation that is commonly
> used/recommended? I  would prefer to begin with anatomically (rather than
> functionally defined) ROIs.
>
> My goal is to parcellate the voxel-wise time series into larger ROIs. I've
> previously used the Desikan-Killiany atlas, but ideally would be interested
> in using something with a finer parcellation.
>
> The only HCP parcellation I was able to find was the parcellation from the
> ICA decomposition (resulting in one timeseries per ICA component), with 25,
> 50, 100, 200, 300 components. However, I don't think this is something I am
> interested in, as a single node (ie component) may comprise voxels that are
> scattered across the brain.
>
> Is there anything like an anatomical ROI parcellation that's typically
> used by HCP people?
>
> Thanks,
> Joelle
>
>
> ___
> HCP-Users mailing list
> HCP-Users@humanconnectome.org
> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>
>
> --
>
> The materials in this message are private and may contain Protected
> Healthcare Information or other information of a sensitive nature. If you
> are not the intended recipient, be advised that any unauthorized use,
> disclosure, copying or the taking of any action in reliance on the contents
> of this information is strictly prohibited. If you have received this email
> in error, please immediately notify the sender via telephone or return mail.
>

___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Re: [HCP-Users] ROI parcellation

[Greg Burgess]

Hi Joelle,

You should be aware of potential issues with using anatomically-defined ROIs 
for rfMRI network analysis.

Smith, S. M., Miller, K. L., Salimi-Khorshidi, G., Webster, M., Beckmann, C. 
F., Nichols, T. E., et al. (2011). Network modelling methods for FMRI. 
NeuroImage, 54(2), 875–891. http://doi.org/10.1016/j.neuroimage.2010.08.063

Gordon, E. M., Laumann, T. O., Adeyemo, B., Huckins, J. F., Kelley, W. M., & 
Petersen, S. E. (2014). Generation and Evaluation of a Cortical Area 
Parcellation from Resting-State Correlations. Cerebral Cortex. 
http://doi.org/10.1093/cercor/bhu239

--Greg


Greg Burgess, Ph.D.
Staff Scientist, Human Connectome Project
Washington University School of Medicine
Department of Neuroscience
Phone: 314-362-7864
Email: gburg...@wustl.edu

> On Dec 15, 2015, at 11:24 AM, Joelle Zimmermann 
>  wrote:
> 
> Hi Michael,
> 
> Thanks! So currently, the 2 available parcellation schemes are the Freesurfer 
> Desikan-Killiany (aparc+aseg.mgz) and Destrieux (aparc.a2009s+aseg.mgz) in 
> the structural extended preprocessed/T1w/mri folder? Im presuming these are 
> in the subject's T1 individual subject space. 
> 
> Are you aware whether these parcellation schemes are already available in the 
> MNI standard space? The goal is to parcellate the functional BOLD data (which 
> are currently in MNI standard space; Ie in the FIX extended package, the 
> MNINonLinear/Results/rfMRI_REST1_LR/rfMRI_REST1_LR_hp2000_clean.nii). Or 
> alternatively, if you could point me to where the volumetric functional BOLD 
> data in T1 space is (I cannot locate it in the FIX extended package - this 
> only seems to have func already normalized to MNI), I could directly apply 
> the aparc+aseg parcellation (that's in T1 space) to this. 
> 
> Thanks,
> Joelle
> 
> 
> 
> On Tue, Dec 15, 2015 at 10:46 AM, Harms, Michael  wrote:
> 
> Hi,
> The only purely anatomical parcellation that is available currently are those 
> provided by FreeSurfer, which you seem to be familiar with.
> 
> If you are interested in a functional parcellation, there is the Gordon et 
> al. parcellation derived from non-HCP rfMRI data.  A parcellation that 
> incorporates the myelin maps and rfMRI data and which is specifically derived 
> from a subset of HCP participants is in the works (from Matt G.)
> 
> 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
> 
> From: Joelle Zimmermann 
> Date: Tuesday, December 15, 2015 9:35 AM
> To: "hcp-users@humanconnectome.org" 
> Subject: [HCP-Users] ROI parcellation
> 
> Hi everyone,
> 
> Does HCP have a specific ROI parcellation that is commonly used/recommended? 
> I  would prefer to begin with anatomically (rather than functionally defined) 
> ROIs.
> 
> My goal is to parcellate the voxel-wise time series into larger ROIs. I've 
> previously used the Desikan-Killiany atlas, but ideally would be interested 
> in using something with a finer parcellation. 
> 
> The only HCP parcellation I was able to find was the parcellation from the 
> ICA decomposition (resulting in one timeseries per ICA component), with 25, 
> 50, 100, 200, 300 components. However, I don't think this is something I am 
> interested in, as a single node (ie component) may comprise voxels that are 
> scattered across the brain.
> 
> Is there anything like an anatomical ROI parcellation that's typically used 
> by HCP people?
> 
> Thanks,
> Joelle
> 
> 
> ___
> HCP-Users mailing list
> HCP-Users@humanconnectome.org
> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
> 
> 
>  
> 
> The materials in this message are private and may contain Protected 
> Healthcare Information or other information of a sensitive nature. If you are 
> not the intended recipient, be advised that any unauthorized use, disclosure, 
> copying or the taking of any action in reliance on the contents of this 
> information is strictly prohibited. If you have received this email in error, 
> please immediately notify the sender via telephone or return mail.
> 
> 
> ___
> HCP-Users mailing list
> HCP-Users@humanconnectome.org
> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
> 


___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Re: [HCP-Users] Verifying HCP data versions

[Harms, Michael]

Determining the recon version ("r177" vs "r227") of old Q1-Q3 released data is different for dMRI vs. fMRI.


For fMRI, we have not ever changed the image reconstruction algorithm for a 
given subject's data across data releases.  So the "fMRI_3T_ReconVrs" variable that is currently available in the database will tell you whether the recon version was r177 or r227 (or, for a small number of subjects there is a mixture of recon versions,
 noted as "r177 r227" for that variable), and that applies regardless of whether you are working with fMRI data from the Q1, Q2, Q3, S500, or S900 releases.


For dMRI, you have to determine the data release of the particular dMRI data you are looking at to infer the recon version.  dMRI data from the Q1 or Q2 releases will have been reconn'ed using the "r177" recon algorithm.  dMRI data from the Q3, S500, and
 S900 releases will have been reconn'ed with the "r227" recon algorithm.


Of note, to avoid any confusion, it is important to realize that the "Release" variable that you see in the database refers to when a given subject was first publicly released, but that does not tell whether the particular data you are looking comes from
 the Q1-Q3, S500, or S900 releases (with the exception of the latest release, since a "Release=S900" subject naturally couldn't have data released in one of the earlier, pre-S900, releases) -- e.g.,  depending on when you downloaded/obtained the particular
 data you are looking at, a subject designated as "Release=Q1" subject in the database could have had its data processed using the Q1 pipelines, the Q2/Q3 pipelines, or the S500/S900 pipelines .


We encourage any users of Q1-Q3 released data to switch to using S500/S900 released data.  S500/S900 released data are processed with a consistent set of pipelines, and differ only in that additional files/data have been added to the S900 released data
 compared to the S500 released data.


Hope that helps.


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






From: Timothy Brown 
Reply-To: Timothy Brown 
Date: Tuesday, December 15, 2015 10:31 AM
To: Matthew George Liptrot , HCP Listserv 
Subject: Re: [HCP-Users] Verifying HCP data versions











Hi Matthew,
 
Re: Your question 1) below about detected which release data is part of
 
I can't really speak to differentiating between Q1 vs. Q2 vs Q3 data, but I can think of a technique that should work and be scriptable for detecting whether a subject's data is from the
500subjects release or the
900subjects release. The technique would be based on the contents of at least 1 release notes file for the subject. 
 
If you have downloaded the structurally preprocessed data package for a subject (e.g.
100307_3T_Structural_preproc.zip) and unzipped that package, then you should have a sub-directory below the directory at which you did the unzipping named
100307 and a sub-directory below that named
release-notes. In the
100307/release-notes sub-directory, you should find a file named
Structural_preproc.txt (the release notes for the Structural_preproc package).
 
I think it might be slightly problematic to count on the modification date of that release notes file as an indication of whether the data is part of the
500subjects release or
900subjects release. In my opinion it is too easy for that file modification date to be inadvertently changed or updated. (The tool used to unzip the package may not preserve modification
 dates; someone might accidentally touch the file and thus change it's modification date; someone may edit the file intending to simply look at it, accidentally add a space, and save the result.)  I think it would be more reliable to differentiate between the
500subjects release and the
900subjects release based on the
contents of the release notes file. (I'm supposing that people are unlikely to purposely change the contents of these files and wouldn't be likely to accidentally change the date written in the file or substantially change the contents.)
 
For the 500subjects release, the first few lines of the release notes file should look something like the following (without the line numbers):

100307_3T_Structural_preproc.zip  Sat Mar 29 13:21:24 CDT 2014Structural Pipeline v3.1Execution 1
  These data were generated and made available by the Human Connectome Project, ...
For the 900subjects release, the first few lines of the release notes file should look something like the following (without the line numbers):

100307_3T_Structural_preproc.zip  Mon Nov 30 23:44:34 CST 2015  These data were generated and made available by the Human Connectome Project,
Since all the 

Re: [HCP-Users] MRI parameters

[Barbara Kreilkamp]

Dear all,

I've acquired the T1w and T2w images on the GE scanner, additionally, as
advised we've acquired a B1 field map.
I've been trying to use the HCP tools for volume to surface registration of
the B1 map, but so far have had no success. I found an mri_vol2surf
co-registration algorithm used within recon-all that I wanted to adapt
(found no related commands in the PostFreesurferPipelineBatch.sh or
SetUpHCPPipeline.sh), but it does not seem to work.

I wonder if you could please help out?
This is what I tried:

flirt -in REF066p_FieldMap.nii.gz -ref T1w/T1w_acpc_dc_restore.nii.gz -dof
6 -out REF066p_FieldMap_coreg.nii.gz


mri_convert -rt nearest -rl T1w/T1w_acpc_dc_restore.nii.gz
REF066p_FieldMap_coreg.nii.gz REF066p_FieldMap_coreg_resliced.nii.gz


mri_vol2surf --mov REF066p_FieldMap_coreg_resliced.nii.gz --hemi lh
--noreshape --interp trilinear --o
REF066p_FieldMap_coreg_resliced.lh.mgz --projfrac 0.3 --regheader REF066p
--cortex


mri_vol2surf --mov REF066p_FieldMap_coreg_resliced.nii.gz --hemi rh
--noreshape --interp trilinear --o REF066p_FieldMap_coreg_resliced.rh.mgh
--projfrac 0.3 --regheader REF066p --cortex



Thank you very much,

Best wishes,

Barbara

On Tue, Dec 1, 2015 at 4:29 PM, Gaurav Patel  wrote:

> Just a warning from another GE user, we have not been able to replicate
> the myelin maps in Glasser/Van Essen with standard GE sequences on our
> MR750 (see previous threads on this forum about that).  If you do have
> success we'd love to know how.  We now have approval to run a GE prototype
> of the MPRAGE on our scanner, so hopefully soon we'll see if that solves
> the problem.
>
> __
>   gaurav patel
>   gauravpa...@gmail.com
>   www.neurofreak.net
>
>
>
>
> On Nov 27, 2015, at 1:15 PM, Harms, Michael wrote:
>
> >
> > Please cc the list, so that others can respond and benefit from the
> exchange.
> >
> > No, we don't have an issue with TR/TE changing between our structural
> scans on Siemens scanners.  Is there perhaps a mode of operation of a GE
> scanner that overrides that sort of behavior, so that it keeps TR/TE
> completely constant?  If you're operating the scanner in a regime where RF
> deposition is near its limit, you might have to intentionally "back off" to
> derive a set of parameters that will basically work for all subjects.
> >
> > 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
> >
> > From: Rachel Woodall 
> > Date: Thursday, November 26, 2015 6:00 AM
> > To: "Harms, Michael" 
> > Subject: Re: [HCP-Users] MRI parameters
> >
> > Hi Michael,
> >
> > Apologies, I probably did not make myself very clear.
> >
> > I set up my scan protocol, assuming that the parameters I used would be
> fixed and the same for every scan.  However, upon checking the DICOM
> information after the scan, the TR and TE have differed from what was input.
> >
> > I have asked my radiographer whether this would be expected and he said
> that the differences between the two sets of parameters are trivial and I
> do not believe (in the absence of the parameters) that you would be able to
> distinguish one from the other.  All GE systems will modify certain
> parameters based on a patients weight (especially FSE T2 waited scans where
> RF deposition is high) and as a consequence the effective TE will vary by a
> few milliseconds.
> >
> > The nature of my project requires a follow up of the same participants
> so I am now concerned that the follow up scan will not match the original
> and what effect this has on the data.
> >
> > Therefore, I wanted to contact someone within the HCP to see if this is
> also something you have experienced when the image parameters have been
> checked post-scan.
> >
> > Thanks again for your help.
> >
> > Kind regards,
> > Rachel
> >
> > On 19 November 2015 at 14:39, Harms, Michael  wrote:
> >>
> >> Hi,
> >> I'm not following the context for the question.  I've never heard of
> people varying TR/TE across participants for structural scans.  Is someone
> suggesting that you do that?When you set up a protocol on a scanner,
> you set the TR/TE, so by default, the values will be the same across
> participants.
> >>
> >> If you vary TR/TE, you are changing the MR contrast, which can have all
> kinds of implications.
> >>
> >> 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
> >>
> >> From: Rachel Woodall 
> >> Date: Thursday, November 19, 20

Re: [HCP-Users] Verifying HCP data versions

[Greg Burgess]

The contents of the Q3 files appear to be:
1. 100307_3T_Structural_preproc.zip
2. 
3. Thu Aug 29 18:30:20 CDT 2013
4. Structural Pipeline v2.0
5. Execution 1
6. 
7. These data were generated and made available by the Human Connectome 
Project...

--Greg


Greg Burgess, Ph.D.
Staff Scientist, Human Connectome Project
Washington University School of Medicine
Department of Neuroscience
Phone: 314-362-7864
Email: gburg...@wustl.edu

> On Dec 15, 2015, at 10:31 AM, Timothy B. Brown  wrote:
> 
> Hi Matthew,
>  
> Re: Your question 1) below about detected which release data is part of
>  
> I can't really speak to differentiating between Q1 vs. Q2 vs Q3 data, but I 
> can think of a technique that should work and be scriptable for detecting 
> whether a subject's data is from the 500subjects release or the 900subjects 
> release. The technique would be based on the contents of at least 1 release 
> notes file for the subject. 
>  
> If you have downloaded the structurally preprocessed data package for a 
> subject (e.g. 100307_3T_Structural_preproc.zip) and unzipped that package, 
> then you should have a sub-directory below the directory at which you did the 
> unzipping named 100307 and a sub-directory below that named release-notes. In 
> the 100307/release-notes sub-directory, you should find a file named 
> Structural_preproc.txt (the release notes for the Structural_preproc package).
>  
> I think it might be slightly problematic to count on the modification date of 
> that release notes file as an indication of whether the data is part of the 
> 500subjects release or 900subjects release. In my opinion it is too easy for 
> that file modification date to be inadvertently changed or updated. (The tool 
> used to unzip the package may not preserve modification dates; someone might 
> accidentally touch the file and thus change it's modification date; someone 
> may edit the file intending to simply look at it, accidentally add a space, 
> and save the result.)  I think it would be more reliable to differentiate 
> between the 500subjects release and the 900subjects release based on the 
> contents of the release notes file. (I'm supposing that people are unlikely 
> to purposely change the contents of these files and wouldn't be likely to 
> accidentally change the date written in the file or substantially change the 
> contents.)
>  
> For the 500subjects release, the first few lines of the release notes file 
> should look something like the following (without the line numbers):
>   • 100307_3T_Structural_preproc.zip
>   •  
>   • Sat Mar 29 13:21:24 CDT 2014
>   • Structural Pipeline v3.1
>   • Execution 1
>   •  
>   • These data were generated and made available by the Human Connectome 
> Project, ...
> For the 900subjects release, the first few lines of the release notes file 
> should look something like the following (without the line numbers):
>   • 100307_3T_Structural_preproc.zip
>   •  
>   • Mon Nov 30 23:44:34 CST 2015
>   •  
>   • These data were generated and made available by the Human Connectome 
> Project,
> Since all the Structural Preproc packages for the 900subjects release were 
> finalized after 31 Oct 2015, you could read in the 3rd line of the release 
> notes file, parse the date, and check to see if the date is before or after 
> 31 Oct 2015.  If it is before 31 Oct 2015, then the data is from the 
> 500subjects release.  If it's after 31 Oct 2015, then the data is from the 
> 900subjects release.
>  
> If parsing and comparing the dates is cumbersome, you could also simply look 
> at the contents of line 4 in the release notes file. If it starts with 
> "Structural Pipeline" then you're working with 500subjects data. If it is a 
> blank line, then you're working with 900subjects data. (In the 900subjects 
> form of the release notes, the pipeline version numbers come at the end of 
> the release notes file instead of right after the date.)
>  
> If you don't have the structurally preprocessed data for a subject, you could 
> probably extrapolate this technique to use the release notes file for the 
> package(s) you do have.
>  
> Off hand, I don't know what the release notes files look like for Q1, Q2, and 
> Q3, but if you have some of that data, you might be able to extend this 
> method to differentiate between those releases by examining the contents of 
> those release notes files.
>  
> I realize that this isn't a particularly elegant mechanism. Maybe someone 
> else can think of a quicker or more elegant solution (maybe simply based on 
> the presence or absence of a particular file generated by the pipelines.)
>  
> The above technique should allow you to differentiate between releases, but 
> as for your question 2), detecting the version of the image reconstruction 
> algorithm applied, I don't have a good answer for that.
>  
> Hope this is at least some

Re: [HCP-Users] Verifying HCP data versions

[Timothy B. Brown]

Hi Matthew,

Re: Your question 1) below about detected which release data is part of

I can't really speak to differentiating between Q1 vs. Q2 vs Q3 data,
but I can think of a technique that should work and be scriptable for
detecting whether a subject's data is from the 500subjects release or
the 900subjects release. The technique would be based on the contents of
at least 1 release notes file for the subject.

If you have downloaded the structurally preprocessed data package for a
subject (e.g. 100307_3T_Structural_preproc.zip) and unzipped that
package, then you should have a sub-directory below the directory at
which you did the unzipping named 100307 and a sub-directory below that
named release-notes. In the 100307/release-notes sub-directory, you
should find a file named Structural_preproc.txt (the release notes for
the Structural_preproc package).

I think it might be slightly problematic to count on the modification
date of that release notes file as an indication of whether the data is
part of the 500subjects release or 900subjects release. In my opinion it
is too easy for that file modification date to be inadvertently changed
or updated. (The tool used to unzip the package may not preserve
modification dates; someone might accidentally touch the file and thus
change it's modification date; someone may edit the file intending to
simply look at it, accidentally add a space, and save the result.)  I
think it would be more reliable to differentiate between the 500subjects
release and the 900subjects release based on the *contents* of the
release notes file. (I'm supposing that people are unlikely to purposely
change the contents of these files and wouldn't be likely to
accidentally change the date written in the file or substantially change
the contents.)

For the 500subjects release, the first few lines of the release
notes file should look something like the following (without the
line numbers):
 1. 100307_3T_Structural_preproc.zip
 2.
 3. Sat Mar 29 13:21:24 CDT 2014
 4. Structural Pipeline v3.1
 5. Execution 1
 6.
 7. These data were generated and made available by the Human Connectome
Project, ... For the 900subjects release, the first few lines of the
release notes file should look something like the following (without
the line numbers):
 1. 100307_3T_Structural_preproc.zip
 2.
 3. Mon Nov 30 23:44:34 CST 2015
 4.
 5. These data were generated and made available by the Human Connectome
Project, Since all the Structural Preproc packages for the
900subjects release were finalized after 31 Oct 2015, you could read
in the 3rd line of the release notes file, parse the date, and check
to see if the date is before or after 31 Oct 2015.  If it is before
31 Oct 2015, then the data is from the 500subjects release.  If it's
after 31 Oct 2015, then the data is from the 900subjects release.

If parsing and comparing the dates is cumbersome, you could also simply
look at the contents of line 4 in the release notes file. If it starts
with "Structural Pipeline" then you're working with 500subjects data. If
it is a blank line, then you're working with 900subjects data. (In the
900subjects form of the release notes, the pipeline version numbers come
at the end of the release notes file instead of right after the date.)

If you don't have the structurally preprocessed data for a subject, you
could probably extrapolate this technique to use the release notes file
for the package(s) you do have.

Off hand, I don't know what the release notes files look like for Q1,
Q2, and Q3, but if you have some of that data, you might be able to
extend this method to differentiate between those releases by examining
the contents of those release notes files.

I realize that this isn't a particularly elegant mechanism. Maybe
someone else can think of a quicker or more elegant solution (maybe
simply based on the presence or absence of a particular file generated
by the pipelines.)

The above technique should allow you to differentiate between releases,
but as for your question 2), detecting the version of the image
reconstruction algorithm applied, I don't have a good answer for that.

Hope this is at least somewhat helpful,

Tim

On Tue, Dec 8, 2015, at 04:26, Matthew George Liptrot wrote:
> Hi,
>
> 1) I understand that some of the processing of HCP data is different
>for the different releases (Q1, Q2/3, 500subjects etc). Is there a
>scriptable way to see which version/release my downloaded data came
>from? (I am working on several different HCP releases with various
>groups of co-workers and it would be nice if my scripts could check
>for this automatically)
>
> 2) I also understand that the image reconstruction method is different
>for some releases (From the wiki: “Two versions of the image
>reconstruction algorithm applied to dMRI and fMRI data have been
>used in HCP to date: version r177 for subjects scanned in Q1
>through mid-Q3, version r227 for sub

Re: [HCP-Users] ROI parcellation

[Harms, Michael]

Hi,
The only purely anatomical parcellation that is available currently are those provided by FreeSurfer, which you seem to be familiar with.


If you are interested in a functional parcellation, there is the Gordon et al. parcellation derived from non-HCP rfMRI data.  A parcellation that incorporates the myelin maps and rfMRI data and which is specifically derived from a subset of HCP participants
 is in the works (from Matt G.)


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







From: Joelle Zimmermann 
Date: Tuesday, December 15, 2015 9:35 AM
To: "hcp-users@humanconnectome.org" 
Subject: [HCP-Users] ROI parcellation





Hi everyone,


Does HCP have a specific ROI parcellation that is commonly used/recommended? I  would prefer to begin with anatomically (rather than functionally defined) ROIs.


My goal is to parcellate the voxel-wise time series into larger ROIs. I've previously used the Desikan-Killiany atlas, but ideally would be interested in using something with a finer parcellation. 


The only HCP parcellation I was able to find was the parcellation from the ICA decomposition (resulting in one timeseries per ICA component), with 25, 50, 100, 200, 300 components. However, I don't think this is something I am interested in, as a single
 node (ie component) may comprise voxels that are scattered across the brain.


Is there anything like an anatomical ROI parcellation that's typically used by HCP people?


Thanks,
Joelle





___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users





 



The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended
 recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone
 or return mail.
___HCP-Users mailing listHCP-Users@humanconnectome.orghttp://lists.humanconnectome.org/mailman/listinfo/hcp-users

[HCP-Users] ROI parcellation

[Joelle Zimmermann]

Hi everyone,

Does HCP have a specific ROI parcellation that is commonly
used/recommended? I  would prefer to begin with anatomically (rather than
functionally defined) ROIs.

My goal is to parcellate the voxel-wise time series into larger ROIs. I've
previously used the Desikan-Killiany atlas, but ideally would be interested
in using something with a finer parcellation.

The only HCP parcellation I was able to find was the parcellation from the
ICA decomposition (resulting in one timeseries per ICA component), with 25,
50, 100, 200, 300 components. However, I don't think this is something I am
interested in, as a single node (ie component) may comprise voxels that are
scattered across the brain.

Is there anything like an anatomical ROI parcellation that's typically used
by HCP people?

Thanks,
Joelle

___
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Re: [HCP-Users] Hcp Data with non-overlapping parcellations

[Matthew George Liptrot]

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" 
mailto:do...@brainvis.wustl.edu>> 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 
mailto:matthew.lipt...@di.ku.dk>> 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   GREENBLUE   ALPHA
  0   ???  0.000   0.000   0.000   0.000
  1   L_bankssts   0.098   0.392   0.157   1.000
  2   L_caudalanteriorcingulate0.490   0.392   0.627   1.000
  3   L_caudalmiddlefrontal0.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   GREENBLUE   ALPHA
  0   ???  0.000   0.000   0.000   0.000
  1   L_bankssts   0.098   0.392   0.157   1.000