Re: [HCP-Users] contrast in human connectome 3T structural MRI

[Xu, Junqian]

Hi Jamila,

These variable bright arteries in the T1w MPRAGE images are probably due to the 
time-of-flight (TOF) effects of those “fresh" arterial blood flowing into the 
brain after the inverse pulse.

http://mriquestions.com/time-of-flight-effects.html 

Regards
Gordon

> On Mar 5, 2018, at 9:15 AM, Glasser, Matthew  wrote:
> 
> No gadolinium contrast was used in the HCP.  Sometimes blood will appear 
> bright on T1w scans for reasons other than gadolinium contrast.
> 
> Peace,
> 
> Matt.
> 
> From:  on behalf of Jamila Ahdidan 
> 
> Date: Monday, March 5, 2018 at 2:53 AM
> To: "hcp-users@humanconnectome.org" 
> Subject: [HCP-Users] contrast in human connectome 3T structural MRI
> 
> Hi,
> 
> I have noticed that many if not all the structural MRIs of the HCP show signs 
> of contrast in the subjects blood. Is that correct? Have you scanned the 
> participants without using contrast as this disturbs the segmentation?
> 
> Thank you.
> 
> Best regards / Cordialement / De bedste hilsner
> 
> Jamila Ahdidan
> PhD, Partner, CSO
> Brainreader ApS
> Emil Møllers Gade 41
> 8700 Horsens - DK
> tel: +45 5050 5544
> email: jam...@brainreader.net
> skype: jamila_ahdidan
> website: www.brainreader.net
> ___
> 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


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

Re: [HCP-Users] pipeline structural PostFreesurfer wmparc not found

[Xu, Junqian]

Tim,

Just FYI (may not be the cause of this particular case) for completeness of 
your documentation, this old ticket is still open (after 6 years) for guest OS 
in VirtualBox.

https://www.virtualbox.org/ticket/10085

Gordon

On Jun 29, 2017, at 11:29 AM, Timothy B. Brown 
> wrote:

Hi,

I'm curious to know more about the file systems in use that would cause the 
symbolic link operation to not be supported.

I think you would be getting this "Operation not supported" error if the file 
system in which your SUBJECTS_DIR exists is a "non-Unix" or "non-Unix-standard" 
file system (maybe a "Windows" file system like FAT32 or NTFS, or some other 
Mac standard file system that also doesn't support symbolic links). If that is 
the case, moving your FREESURFER_HOME (FreeSurfer installation directory) over 
to the file system where your subject data is stored will not do you any good. 
If symbolic links are not supported on that file system, moving more files to 
that file system will not help.

If this is the case, then moving the subject data to a file system that does 
support symbolic links might be a good move. Do you manage the file system that 
appears to be mounted at /mnt/macdata?  Can you move the subject data elsewhere 
to a file system that does support symbolic links?

Assuming that the file system in which FreeSurfer is installed is one that does 
support symbolic links, then moving the subject data over to that file system 
might be another way to alleviate the current problem. But as you wrote, you 
may have a space limit that prevents moving all the subject data over to that 
file system.

If that is the case, then temporarily moving the data for a subject that is 
being processed through the pipelines over to the same file system on which 
FreeSurfer is installed might do the trick. (Move or copy the data for a 
subject to be processed, run the pipelines on that subject, and then move the 
data back to where it was.) This will, of course, add significant copying time 
to the beginning and end of each of your pipeline runs.

Another option would be to try to take advantage of the fact that recon-all 
doesn't try to create the symbolic link if there is already an fsaverage 
directory in your .../HCP_project/Pipelines_ExampleData/subjects/hcp350014/T1w 
directory.  Before processing the data, copy the appropriate fsaverage 
directory from the FreeSurfer installation directory into an fsaverage 
directory for your subject ($SUBJECTS_DIR/fsaverage).

However, a very brief look through the recon-all script indicates that this is 
just one case in which it relies on being able to create a symbolic link. I 
haven't specifically determined if those other uses of symbolic links are ones 
that are invoked by the HCP Pipeline scripts. But this option would only really 
deal with one of those cases. It seems clear to me that recon-all is written 
with the expectation that your data resides on a file system that supports 
symbolic links. So moving in that direction (either by moving all your data to 
such a file system or temporarily moving the data for each subject as it is 
processed) is, I think, the way to go.

Hope that is helpful,

  Tim

On 06/29/2017 12:18 PM, Mandelli, Maria Luisa wrote:
Hi! I think I found the problem and I saw that someone else had the same issues 
before

when it tries to create the symbolic link it fails. Here

ln -s $FREESURFER_HOME/subjects/fsaverage .
ln: failed to create symbolic link `./fsaverage': Operation not supported

In old post someone suggest to set the SUBJECTs_DIR to be on the same file 
system as $FREESURFER_HOME...I can try one case but eventually if I have more 
subjects I dont think I can because of space limit

Let me know if you have suggestions!
Thank you very much

Maria Luisa Mandelli, PhD
Assistant Professional Researcher

University of California, San Francisco
675 Nelson Rising Lane, Suite 190 | San Francisco, CA 94158



Language Neurobiology Lab
http://albalab.ucsf.edu/
Memory and Aging Center
http://memory.ucsf.edu/
UCSF Dyslexia Center
http://dyslexia.ucsf.edu/


From: Glasser, Matthew 
Sent: Wednesday, June 28, 2017 4:30:28 PM
To: 

Re: [HCP-Users] Question about unprocessed fMRI data

[Xu, Junqian]

Hi Ben,

Yes, the CMRR multiband sequence incorporates "dynamic off-resonance in 
k-space” (DORK)” method as in Pfeuffer et al., MRM 2002, which has already been 
implemented in the Siemens product EPI sequence ICE recon.

Gordon
 
> On Jun 8, 2017, at 12:05 PM, Benjamin Risk  wrote:
> 
> Dear HCP experts,
> 
> I am trying to better understand the unprocessed fMRI data. Does the online 
> reconstruction include corrections for spatial shifts due to B0 fluctuations? 
> There is a note about this in Ugurbil et al 2013 but I am wondering if this 
> applies to the final HCP acquisition protocol. 
> 
> Thank you!
> Ben Risk
> 
> ___
> 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] MELODIC denoising vs. released ICA-FIX datasets

[Xu, Junqian]

> On Oct 4, 2016, at 9:03 PM, Ely, Benjamin  wrote:
> 
> Thanks Steve, that's good to keep in mind. Our acquisition is a single 
> "HCP-like" 15 minute run at MB6, 2.1mm isotropic resolution, TR=1s, AP phase 
> encoding, 32-channel head coil on a 3T Skyra; hopefully that gives us a 
> similar temporal profile.

It’s not much about the acquisition protocol (though in the multiband era, MB 
is now related to scanner transmitter stability), but rather the scanner 
stability itself.

> Sounds like I should compare our temporal stability against the HCP's - is 
> there a measure you recommend?

HCP Connectom Skyra scanner has quite small temporal drift and a very linear 
trend (specific to the gradient and body coil hardware characteristics), which 
a typical Skyra can’t match. To determine what detrending cutoff you should use 
for your site-specific data, you could run a 5-10min fBIRN phantom scan with 
your fMRI protocol and look at the scanner stability.

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

Re: [HCP-Users] MELODIC denoising vs. released ICA-FIX datasets

[Xu, Junqian]

> On Oct 4, 2016, at 9:03 PM, Ely, Benjamin  wrote:
> 
> Thanks Steve, that's good to keep in mind. Our acquisition is a single 
> "HCP-like" 15 minute run at MB6, 2.1mm isotropic resolution, TR=1s, AP phase 
> encoding, 32-channel head coil on a 3T Skyra; hopefully that gives us a 
> similar temporal profile.

It’s not much about the acquisition protocol (though in the multiband era, MB 
is now related to scanner transmitter stability), but rather the scanner 
stability itself.

> Sounds like I should compare our temporal stability against the HCP's - is 
> there a measure you recommend?

HCP Connectom Skyra scanner has quite small temporal drift and a very linear 
trend (specific to the gradient and body coil hardware characteristics), which 
a typical Skyra can’t match. To determine what detrending cutoff you should use 
for your site-specific data, you could run a 5-10min fBIRN phantom scan with 
your fMRI protocol and look at the scanner stability.

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

Re: [HCP-Users] fat suppression and diffusion scans

[Xu, Junqian]

Siemens strong fat suppression” = fat sat pulse + gradient reversal

 On Jul 9, 2015, at 2:37 PM, Mark A. Pinsk mpi...@gmail.com wrote:
 
 Hi Michael
 
 Thanks for that information, very helpful.
 
 I forgot to mention that we haven't requested the HCP sequences at this point 
 since we have the Siemens MB sequences installed (we may end up requesting 
 them at some point).  In any case this first test protocol I created was 
 using the stock non-MB Siemens sequence.
 
 Sounds like until we request the HCP sequence, I will use the Siemens strong 
 fat suppression, and I'll have to check what the Siemens MB diffusion 
 sequence offers for fat suppression (presumably it does not have your grad 
 rev fat supp option).
 
 best
 mark
 
 
 
 
 
 On Thu, Jul 9, 2015 at 2:30 PM, Harms, Michael mha...@wustl.edu wrote:
 
 Hi Mark,
 The locked sequences that we are using for HCP, and on which those protocol 
 print-outs are based, are based on a fairly old (at this point) version of 
 the CMRR sequences, for which Fatsat = none actually means that a gradient 
 reversal based method of fat suppression is used rather than RF pulses.
 
 Subsequently at some point in the MB sequence development, this Grad. rev. 
 fat suppr. option was explicitly added as its own variable to the UI, rather 
 than implicitly invoked by Fatsat = none.  I assume that you will be using 
 the current version of the publicly available MB sequences (R012b), which 
 includes this Grad. rev. fat suppr. option.
 
 So, if you are implementing a Prisma protocol, you should also 
 cross-referencing your parameter choices against the LifeSpan protocol for 
 the 3T Prisma at CMRR, which you can find here:
 http://lifespan.humanconnectome.org/data/LSCMRR_3T_printout_2014.08.15.pdf
 
 In that, you will see that
 Fat suppr. = None
 Grad. rev. fat suppr. = Enabled
 
 The combination of those settings will match what is occurring under the 
 hood for the HCP scans (and obviously will match what we are using for the 
 LifeSpan 3T Prisma acquisitions).
 
 Give those settings a try, and see if they eliminate your fat artifacts.
 
 BTW: The reason that we use the gradient reversal rather than RF pulses is 
 that you get a small improvement on the SAR front.
 
 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: Mark A. Pinsk mpi...@gmail.com
 Date: Thursday, July 9, 2015 12:50 PM
 To: hcp-users@humanconnectome.org hcp-users@humanconnectome.org
 Subject: [HCP-Users] fat suppression and diffusion scans
 
 Hi 
 
 We've set up a diffusion protocol at our Prisma following HCP recommendations 
 in Q3_Appendix_I.
 
 I noticed that you leave fat suppression turned off, and I'm curious if 
 there's a reason for that?  
 
 From my initial scans this morning, we get prominent fat artifacts at b=3000, 
 which seem to go away if we turn on strong fat suppression.   (I didn't get 
 a chance to test the other fat supp methods (weak fatsat, SPAIR, water 
 excite)).
 
 Just wanted to check in before I leave strong fat sat turned on in our 
 protocol as a default.
 
 thanks!
 Mark
 
 
 ___
 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] Myelin mapping with FLAIR

[Xu, Junqian]

You can take a look at the UK Biobank project FLAIR protocol first and start 
your site-specific piloting from there.

http://users.fmrib.ox.ac.uk/~steve/BiobankPiloting/

On Jun 18, 2015, at 10:56 AM, Michael Dwyer 
mgdw...@bnac.netmailto:mgdw...@bnac.net wrote:

Dear HCP experts,

First, I would like to thank you all for a great and informative course last 
week. I really enjoyed the interleaved lectures and practicals, and everything 
was extremely well organized

I think Matt had mentioned during the course that the T1/T2 myelin mapping 
could also work with FLAIR. We are acquiring a hi-res 3D-FLAIR clinically on a 
GE scanner, and I was hoping you could give some pointers on the best way to 
acquire it.

I assume we should avoid pre-scan re-calibration, but is there anything else 
special we should do?

Thanks in advance.

Best,
Mike


--
Michael G. Dwyer, Ph.D.
Assistant Professor of Neurology and Biomedical Informatics
Director of Technical Imaging Development
Buffalo Neuroimaging Analysis Center
University at Buffalo
100 High St. Buffalo NY 14203
mgdw...@bnac.netmailto:mgdw...@bnac.net
(716) 859-7065

___
HCP-Users mailing list
HCP-Users@humanconnectome.orgmailto: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] rsfMRI at 7 Tesla

[Xu, Junqian]

Matt,

Please keep in mind Marta is using a 24ch coil, instead of a 32ch coil at 7T. I 
would recommend keeping 1.6 mm and evaluate IPAT2+MB3 or IPAT2+MB4 with the 
24ch coil.

Gordon

On Mar 24, 2015, at 11:07 AM, Glasser, Matthew 
glass...@wusm.wustl.edumailto:glass...@wusm.wustl.edu wrote:

I would get at least 30 min of resting state if not more so that your estimates 
are more stable.  The faster your TR, the better you will be able to clean your 
data and the more robust multivariate statistics like ICA will be.

I would recommend the spin echo field map approach (i.e. using topup).

The extant HCP pipelines work fine for processing 7T data provided on has 3T 
anatomical data.  Making a 7T structural pipeline would be its own research 
project that might become obsolete as soon as parallel transmit becomes more 
common at 7T.

Peace,

Matt.

From: Marta Moreno mmorenoort...@icloud.commailto:mmorenoort...@icloud.com
Date: Tuesday, March 24, 2015 at 7:59 AM
To: Matt Glasser glass...@wusm.wustl.edumailto:glass...@wusm.wustl.edu
Cc: hcp-users@humanconnectome.orgmailto:hcp-users@humanconnectome.org 
hcp-users@humanconnectome.orgmailto:hcp-users@humanconnectome.org
Subject: Re: [HCP-Users] rsfMRI at 7 Tesla

Matt,

Want to keep 1.6.
I am doing IPAT=2
Just for resting state, not tasks, for 20 min.

Your recommendation would be MB5 with TR=962 better than MB4 with TR=1090?

Fieldmap 1.6*1.6*2 is not working well enough. How did you acquire your 
Fieldmap? Any suggestion for improvement (see attachment if needed)?

Finally, will be an available HCP pipeline online for 7 tesla sometime soon? I 
am using SPM now.

Thank you very much for this communication!!

Best wishes always,

Leah

Sent from my iPhone

On Mar 24, 2015, at 6:53 AM, Glasser, Matthew 
glass...@wusm.wustl.edumailto:glass...@wusm.wustl.edu wrote:

We used ipat=2 MB=5 for 1.6mm isotropic data with TR=1s (for reasons of 
improving temporal cleanup, I might be inclined to do 2mm and shorten the TR 
further like the 3T HCP data, but there are still active investigations into 
whether the 1.6mm data allow us to see finer details).  The main trick with the 
7T HCP data is that we are using the 3T structural scans (T1w and T2w at 
0.7mm).  The 3D T2w SPACE is hard to get at 7T because of SAR issues, and T1w 
MPRAGEs are much more inhomgeneous in their flip angles than at 3T, though 
hopefully it will be more possible when parallel transmit becomes more standard.

The grayordinatewise CNR is dramatically higher in the 7T HCP data, however.

Peace,

Matt.

From: Marta Moreno mmorenoort...@icloud.commailto:mmorenoort...@icloud.com
Date: Tuesday, March 24, 2015 at 3:52 AM
To: hcp-users@humanconnectome.orgmailto:hcp-users@humanconnectome.org 
hcp-users@humanconnectome.orgmailto:hcp-users@humanconnectome.org
Subject: [HCP-Users] rsfMRI at 7 Tesla

Hi users,

I am studying preliminary data in order to define my protocol at 7 Tesla 
following some comments I posted here some time ago. I am testing rsfMRI 
1.6x1.6x1.6:
1. MB5 TR=962 vs MB4 TR=1090
2. B0Fieldmap vs Topups
High order and degree shimming (1st and 2nd), 24channel coil.
My conclusion is MB4 TR=1090 and Topups.

Will test tomorrow high order and degree shimming (3rd and 4th degree), 
quadrature.

Wanted to here some expert opinions… I would like to acquire data to be 
processed through the HCP whenever it is possible.
I attached very preliminary protocol just in case you can take a look and give 
me some feedback.

Thank you very much for your help in advance,

Leah

___
HCP-Users mailing list
HCP-Users@humanconnectome.orgmailto:HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-usershttps://urldefense.proofpoint.com/v2/url?u=http-3A__lists.humanconnectome.org_mailman_listinfo_hcp-2Dusersd=AwMF-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=3I6-yvEg8KFim9hIErhCvm3QH8yehzFWJ6HsWQoeUT8m=3DuPvrqJJ8mO17C1L59ex8HVPzQps0TmrZD4-bTAaqgs=P8AZYLbcpxf1vS4Ty9254BsJTNUKzwRlcuuJ-39c7kce=
___
Marta Moreno-Ortega, Ph.D.
Postdoctoral Research Fellow
Division of Experimental Therapeutics
New York State Psychiatric Institute
Department of Psychiatry
Columbia University College of Physicians and Surgeons







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.



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, 

Re: [HCP-Users] error when processing more than 2 tasks with GenericfMRIVolume script

[Xu, Junqian]

Tim,

A patch here to use array instead of space delimited string might be helpful 
for error detection:

e.g.

Tasklist=(domino0 domino1 domino2 domino3)
PhaseEncodinglist=(y y- y y-)

nTasklist=${#Tasklist[@]}
nPhaseEncodinglist=${#PhaseEncodinglist[@]}

if [ $nTasklist -ne $nPhaseEncodinglist ]; then
   Error message
fi


Gordon

 On Dec 9, 2014, at 3:33 PM, Glasser, Matthew glass...@wusm.wustl.edu wrote:
 
 You need to expand the PhaseEncodinglist variable to have the same length as 
 the Tasklist variable (i.e. same number of elements separated by spaces).  
 This probably should be made clearer in the comments for these variables.  
 
 Peace,
 
 Matt.
 
 From: Book, Gregory gregory.b...@hhchealth.org
 Date: Tuesday, December 9, 2014 at 2:19 PM
 To: Matt Glasser glass...@wusm.wustl.edu, hcp-users@humanconnectome.org 
 hcp-users@humanconnectome.org
 Subject: RE: [HCP-Users] error when processing more than 2 tasks with 
 GenericfMRIVolume script
 
 Thanks, the script is attached. Also the directory structure is after the 
 script.
  
 #!/bin/bash 
  
 get_batch_options() {
 local arguments=($@)
  
 unset command_line_specified_study_folder
 unset command_line_specified_subj_list
 unset command_line_specified_run_local
  
 local index=0
 local numArgs=${#arguments[@]}
 local argument
  
 while [ ${index} -lt ${numArgs} ]; do
 argument=${arguments[index]}
  
 case ${argument} in
 --StudyFolder=*)
 command_line_specified_study_folder=${argument/*=/}
 index=$(( index + 1 ))
 ;;
 --Subjlist=*)
 command_line_specified_subj_list=${argument/*=/}
 index=$(( index + 1 ))
 ;;
 --runlocal)
 command_line_specified_run_local=TRUE
 index=$(( index + 1 ))
 ;;
 esac
 done
 }
  
 get_batch_options $@
  
 StudyFolder=/home/pipeline/onrc/data/pipeline/S3777AUX/4/HCPfMRI-dominoSkyra
 Subjlist=analysis
 EnvironmentScript=/opt/HCP/HCP/Examples/Scripts/SetUpHCPPipeline.sh
  
 if [ -n ${command_line_specified_study_folder} ]; then
 StudyFolder=${command_line_specified_study_folder}
 fi
  
 if [ -n ${command_line_specified_subj_list} ]; then
 Subjlist=${command_line_specified_subj_list}
 fi
  
 # Requirements for this script
 #  installed versions of: FSL (version 5.0.6), FreeSurfer (version 5.3.0-HCP) 
 , gradunwarp (HCP version 1.0.1)
 #  environment: FSLDIR , FREESURFER_HOME , HCPPIPEDIR , CARET7DIR , PATH (for 
 gradient_unwarp.py)
  
 #Set up pipeline environment variables and software
 . ${EnvironmentScript}
  
 # Log the originating call
 echo $@
  
 #if [ X$SGE_ROOT != X ] ; then
 QUEUE=-q long.q
 #fi
  
 PRINTCOM=
 #PRINTCOM=echo
 #QUEUE=-q veryshort.q
  
 ## INPUTS 
 ##
  
 #Scripts called by this script do NOT assume anything about the form of the 
 input names or paths.
 #This batch script assumes the HCP raw data naming convention, e.g. for 
 tfMRI_EMOTION_LR and tfMRI_EMOTION_RL:
  
 # 
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_tfMRI_EMOTION_LR.nii.gz
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_tfMRI_EMOTION_LR_SBRef.nii.gz
  
 # 
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_tfMRI_EMOTION_RL.nii.gz
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_tfMRI_EMOTION_RL_SBRef.nii.gz
  
 # 
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_SpinEchoFieldMap_LR.nii.gz
 # 
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_SpinEchoFieldMap_RL.nii.gz
  
 # 
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_SpinEchoFieldMap_LR.nii.gz
 # 
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_SpinEchoFieldMap_RL.nii.gz
  
 #Change Scan Settings: Dwelltime, FieldMap Delta TE (if using), and 
 $PhaseEncodinglist to match your images
 #These are set to match the HCP Protocol by default
  
 #If using gradient distortion correction, use the coefficents from your 
 scanner
 #The HCP gradient distortion coefficents are only available through Siemens
 #Gradient distortion in standard scanners like the Trio is much less than for 
 the HCP Skyra.
  
 #To get accurate EPI distortion correction with TOPUP, the flags in 
 PhaseEncodinglist must match the phase encoding
 #direction of the EPI scan, and you must have used the correct images in 
 SpinEchoPhaseEncodeNegative and Positive
 #variables.  If the distortion is twice as bad as in the original images, 
 flip either the order of the spin echo
 #images or reverse the phase encoding list flag.  The pipeline expects you to 
 have used the same phase encoding
 

Re: [HCP-Users] error when processing more than 2 tasks with GenericfMRIVolume script

[Xu, Junqian]

After a second thought, maybe convert the list to array specifically for the 
comparison purpose so the rest of the pipeline script don’t need to be modified 
to use array indexing.

Tasklist=domino0 domino1 domino2 domino3
PhaseEncodinglist=y y- y y-“

TaskArray=($Tasklist)
PhaseEncodingArray=($PhaseEcondinglist)

nTaskArray=${#TaskArray[@]}
nPhaseEncodingArray=${#PhaseEncodingArray[@]}

if [ $nTaskArray -ne $nPhaseEncodingArray ]; then
 Error message
fi

Gordon

 On Dec 9, 2014, at 4:05 PM, Glasser, Matthew glass...@wusm.wustl.edu wrote:
 
 Thanks Gordon, that would help too.
 
 On 12/9/14, 3:03 PM, Xu, Junqian junqian...@mssm.edu wrote:
 
 Tim,
 
 A patch here to use array instead of space delimited string might be
 helpful for error detection:
 
 e.g.
 
 Tasklist=(domino0 domino1 domino2 domino3)
 PhaseEncodinglist=(y y- y y-)
 
 nTasklist=${#Tasklist[@]}
 nPhaseEncodinglist=${#PhaseEncodinglist[@]}
 
 if [ $nTasklist -ne $nPhaseEncodinglist ]; then
  Error message
 fi
 
 
 Gordon
 
 On Dec 9, 2014, at 3:33 PM, Glasser, Matthew glass...@wusm.wustl.edu
 wrote:
 
 You need to expand the PhaseEncodinglist variable to have the same
 length as the Tasklist variable (i.e. same number of elements separated
 by spaces).  This probably should be made clearer in the comments for
 these variables.
 
 Peace,
 
 Matt.
 
 From: Book, Gregory gregory.b...@hhchealth.org
 Date: Tuesday, December 9, 2014 at 2:19 PM
 To: Matt Glasser glass...@wusm.wustl.edu,
 hcp-users@humanconnectome.org hcp-users@humanconnectome.org
 Subject: RE: [HCP-Users] error when processing more than 2 tasks with
 GenericfMRIVolume script
 
 Thanks, the script is attached. Also the directory structure is after
 the script.
 
 #!/bin/bash
 
 get_batch_options() {
local arguments=($@)
 
unset command_line_specified_study_folder
unset command_line_specified_subj_list
unset command_line_specified_run_local
 
local index=0
local numArgs=${#arguments[@]}
local argument
 
while [ ${index} -lt ${numArgs} ]; do
argument=${arguments[index]}
 
case ${argument} in
--StudyFolder=*)
command_line_specified_study_folder=${argument/*=/}
index=$(( index + 1 ))
;;
--Subjlist=*)
command_line_specified_subj_list=${argument/*=/}
index=$(( index + 1 ))
;;
--runlocal)
command_line_specified_run_local=TRUE
index=$(( index + 1 ))
;;
esac
done
 }
 
 get_batch_options $@
 
 
 StudyFolder=/home/pipeline/onrc/data/pipeline/S3777AUX/4/HCPfMRI-dominoS
 kyra
 Subjlist=analysis
 EnvironmentScript=/opt/HCP/HCP/Examples/Scripts/SetUpHCPPipeline.sh
 
 if [ -n ${command_line_specified_study_folder} ]; then
StudyFolder=${command_line_specified_study_folder}
 fi
 
 if [ -n ${command_line_specified_subj_list} ]; then
Subjlist=${command_line_specified_subj_list}
 fi
 
 # Requirements for this script
 #  installed versions of: FSL (version 5.0.6), FreeSurfer (version
 5.3.0-HCP) , gradunwarp (HCP version 1.0.1)
 #  environment: FSLDIR , FREESURFER_HOME , HCPPIPEDIR , CARET7DIR ,
 PATH (for gradient_unwarp.py)
 
 #Set up pipeline environment variables and software
 . ${EnvironmentScript}
 
 # Log the originating call
 echo $@
 
 #if [ X$SGE_ROOT != X ] ; then
QUEUE=-q long.q
 #fi
 
 PRINTCOM=
 #PRINTCOM=echo
 #QUEUE=-q veryshort.q
 
 ## INPUTS
 ##
 
 #Scripts called by this script do NOT assume anything about the form of
 the input names or paths.
 #This batch script assumes the HCP raw data naming convention, e.g. for
 tfMRI_EMOTION_LR and tfMRI_EMOTION_RL:
 
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_t
 fMRI_EMOTION_LR.nii.gz
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_t
 fMRI_EMOTION_LR_SBRef.nii.gz
 
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_t
 fMRI_EMOTION_RL.nii.gz
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_t
 fMRI_EMOTION_RL_SBRef.nii.gz
 
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_S
 pinEchoFieldMap_LR.nii.gz
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_LR/${Subject}_3T_S
 pinEchoFieldMap_RL.nii.gz
 
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_S
 pinEchoFieldMap_LR.nii.gz
 #
 ${StudyFolder}/${Subject}/unprocessed/3T/tfMRI_EMOTION_RL/${Subject}_3T_S
 pinEchoFieldMap_RL.nii.gz
 
 #Change Scan Settings: Dwelltime, FieldMap Delta TE (if using), and
 $PhaseEncodinglist to match your images
 #These are set to match the HCP Protocol by default
 
 #If using gradient distortion correction, use the coefficents from your
 scanner
 #The HCP gradient distortion coefficents are only available through
 Siemens
 #Gradient distortion in standard scanners like

Re: [HCP-Users] T1UnwarpDir

[Xu, Junqian]

On Oct 26, 2014, at 9:21 AM, Glasser, Matthew 
glass...@wusm.wustl.edumailto:glass...@wusm.wustl.edu wrote:

That note in the pipeline example code was put there because I donąt know
how to tell what readout direction was used from the DICOMs and z seems to
be the Siemens default.  If someone else does, I’d be interested in what
field(s) they used.

It may take some deductive work. Mike Harms once figured out the phase encoding 
direction from the DICOM header. We just need to find the corresponding code of 
slice direction in the DICOM header. The one left is the readout direction. 
However, to be completely sure about the sign would be tough or might be 
impossible from the DICOM header alone.

Gordon, I’d be a bit surprised here if the shim mattered given how small
the correction is already and the fact that the bulk of the correction is
likely to be the same from one shim to another.

I agree that the bulk of the correction is not likely to change between 
re-shims. However, I assume the main reason to do readout distortion correction 
is for regions close to sinuses, where local fields could vary substantially 
between re-shims with global (whole brain) optimization.

 I don’t think it’s likely
to be made worse by reshiming, just won’t be quite as precise of a
correction.

I agree that no matter what it is a “small” effect. However I don’t completely 
agree it can’t be made worse by a wrong fieldmap due to re-shimming. I think we 
can do an experiment of: Fieldmap - Structural - re-shim - wrong Fieldmap, to 
evaluate.

Gordon


Peace,

Matt.

On 10/24/14, 10:33 PM, Xu, Junqian 
junqian...@mssm.edumailto:junqian...@mssm.edu wrote:

As for importance, it depends on your application but readout distortion
is typically quite small. Btw, weąve observed that the scanner
re-shimming often happens between the fieldmap and the structural scans
if the scanner operator is not well-educated for the importance of
preventing re-shimming. In such cases, I think it is better to disable
the readout distortion correction in the PreFreeSurferPipeline.

Gordon

On Oct 24, 2014, at 11:18 PM, Xu, Junqian 
junqian...@mssm.edumailto:junqian...@mssm.edu wrote:

'Unwarp Dirą should correspond to the Readout (frequency encoding)
direction for the ŚPreFreeSurferPipeline', in which case is the Z
direction (Head - Foot) for the sagittal T1w/T2w HCP structural
acquisitions. Not sure what you mean by The only comment is that z
appears best.˛ Below is whatąs in PreFreeSurfer/PreFreeSurferPipeline.sh

--unwarpdir={x, y, z}  Readout direction of the T1w and T2w
images
 (Used with either a regular
field map or a spin
 echo field map)


On Oct 24, 2014, at 8:28 PM, Micah Chambers 
micahc...@gmail.commailto:micahc...@gmail.com
wrote:

Could anyone provide a better explanation of the importance of Unwarp
Dir in the example file 'PreFreeSurferPipelineBatch.sh'? The only
comment is that z appears best. It seems like direction of warping
should be a known value, is that not the case.

I don't know if this is related, but I have been testing the scripts
with HCP subject 901038 and I am finding that the outputs do not match
up. There is a slight tilt to the head. While not a big issue (the
brain is still labeled correctly), it makes validation of scripts
harder. Has anyone else had such an issue? I have included screenshots
(ours.png is our local version, hcp.png is the downloaded version).
Note that this came from '901038_3T_Structural_preproc.zip' and was
downloaded about a month ago.

Thanks

-MIcah

--
Micah Chambers, M.S.
Ahmanson-Lovelace Brain Mapping Center
University of California Los Angeles
635 Charles E. Young Drive SW, Suite 225
Los Angeles, CA 90095-7334
310-206-2101 (Office)
310-206-5518 (Fax)
703-307-7692 (Cell)
email: mica...@ucla.edumailto:mica...@ucla.edu


___
HCP-Users mailing list
HCP-Users@humanconnectome.orgmailto:HCP-Users@humanconnectome.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.humanconnectom
e.org_mailman_listinfo_hcp-2Dusersd=AAIGaQc=4R1YgkJNMyVWjMjneTwN5tJRn8
m8VqTSNCjYLg1wNX4r=3I6-yvEg8KFim9hIErhCvm3QH8yehzFWJ6HsWQoeUT8m=UEyeqf
3jP4WJpWQN5X0VinWErEJz5X0LwGv9I9bKTaEs=VGju-usV7cI7ZgqageB_YKPSrZ9SFw22
f0BHVq4UfxAe=

ours.pnghcp.png


___
HCP-Users mailing list
HCP-Users@humanconnectome.orgmailto:HCP-Users@humanconnectome.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.humanconnectome
.org_mailman_listinfo_hcp-2Dusersd=AAIGaQc=4R1YgkJNMyVWjMjneTwN5tJRn8m8
VqTSNCjYLg1wNX4r=3I6-yvEg8KFim9hIErhCvm3QH8yehzFWJ6HsWQoeUT8m=UEyeqf3jP
4WJpWQN5X0VinWErEJz5X0LwGv9I9bKTaEs=VGju-usV7cI7ZgqageB_YKPSrZ9SFw22f0BH
Vq4UfxAe=


___
HCP-Users mailing list
HCP-Users@humanconnectome.orgmailto:HCP-Users@humanconnectome.org
https://urldefense.proofpoint.com/v2/url?u=http

Re: [HCP-Users] T1UnwarpDir

[Xu, Junqian]

'Unwarp Dir’ should correspond to the Readout (frequency encoding) direction 
for the ‘PreFreeSurferPipeline', in which case is the Z direction (Head - Foot) 
for the sagittal T1w/T2w HCP structural acquisitions. Not sure what you mean by 
The only comment is that z appears best.” Below is what’s in 
PreFreeSurfer/PreFreeSurferPipeline.sh

  --unwarpdir={x, y, z}  Readout direction of the T1w and T2w images
   (Used with either a regular field 
map or a spin
   echo field map)


 On Oct 24, 2014, at 8:28 PM, Micah Chambers micahc...@gmail.com wrote:
 
 Could anyone provide a better explanation of the importance of Unwarp Dir in 
 the example file 'PreFreeSurferPipelineBatch.sh'? The only comment is that z 
 appears best. It seems like direction of warping should be a known value, is 
 that not the case.
 
 I don't know if this is related, but I have been testing the scripts with HCP 
 subject 901038 and I am finding that the outputs do not match up. There is a 
 slight tilt to the head. While not a big issue (the brain is still labeled 
 correctly), it makes validation of scripts harder. Has anyone else had such 
 an issue? I have included screenshots (ours.png is our local version, hcp.png 
 is the downloaded version). Note that this came from 
 '901038_3T_Structural_preproc.zip' and was downloaded about a month ago.
 
 Thanks
 
 -MIcah
 
 -- 
 Micah Chambers, M.S.
 Ahmanson-Lovelace Brain Mapping Center
 University of California Los Angeles
 635 Charles E. Young Drive SW, Suite 225 
 Los Angeles, CA 90095-7334
 310-206-2101 (Office)
 310-206-5518 (Fax)
 703-307-7692 (Cell)
 email: mica...@ucla.edu
 
 
 ___
 HCP-Users mailing list
 HCP-Users@humanconnectome.org
 http://lists.humanconnectome.org/mailman/listinfo/hcp-users
 
 ours.pnghcp.png


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

Re: [HCP-Users] T1UnwarpDir

[Xu, Junqian]

As for importance, it depends on your application but readout distortion is 
typically quite small. Btw, we’ve observed that the scanner re-shimming often 
happens between the fieldmap and the structural scans if the scanner operator 
is not well-educated for the importance of preventing re-shimming. In such 
cases, I think it is better to disable the readout distortion correction in the 
PreFreeSurferPipeline.

Gordon

 On Oct 24, 2014, at 11:18 PM, Xu, Junqian junqian...@mssm.edu wrote:
 
 'Unwarp Dir’ should correspond to the Readout (frequency encoding) direction 
 for the ‘PreFreeSurferPipeline', in which case is the Z direction (Head - 
 Foot) for the sagittal T1w/T2w HCP structural acquisitions. Not sure what you 
 mean by The only comment is that z appears best.” Below is what’s in 
 PreFreeSurfer/PreFreeSurferPipeline.sh
 
  --unwarpdir={x, y, z}  Readout direction of the T1w and T2w images
   (Used with either a regular field 
 map or a spin
   echo field map)
 
 
 On Oct 24, 2014, at 8:28 PM, Micah Chambers micahc...@gmail.com wrote:
 
 Could anyone provide a better explanation of the importance of Unwarp Dir in 
 the example file 'PreFreeSurferPipelineBatch.sh'? The only comment is that z 
 appears best. It seems like direction of warping should be a known value, is 
 that not the case.
 
 I don't know if this is related, but I have been testing the scripts with 
 HCP subject 901038 and I am finding that the outputs do not match up. There 
 is a slight tilt to the head. While not a big issue (the brain is still 
 labeled correctly), it makes validation of scripts harder. Has anyone else 
 had such an issue? I have included screenshots (ours.png is our local 
 version, hcp.png is the downloaded version). Note that this came from 
 '901038_3T_Structural_preproc.zip' and was downloaded about a month ago.
 
 Thanks
 
 -MIcah
 
 -- 
 Micah Chambers, M.S.
 Ahmanson-Lovelace Brain Mapping Center
 University of California Los Angeles
 635 Charles E. Young Drive SW, Suite 225 
 Los Angeles, CA 90095-7334
 310-206-2101 (Office)
 310-206-5518 (Fax)
 703-307-7692 (Cell)
 email: mica...@ucla.edu
 
 
 ___
 HCP-Users mailing list
 HCP-Users@humanconnectome.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.humanconnectome.org_mailman_listinfo_hcp-2Dusersd=AAIGaQc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=3I6-yvEg8KFim9hIErhCvm3QH8yehzFWJ6HsWQoeUT8m=UEyeqf3jP4WJpWQN5X0VinWErEJz5X0LwGv9I9bKTaEs=VGju-usV7cI7ZgqageB_YKPSrZ9SFw22f0BHVq4UfxAe=
  
 
 ours.pnghcp.png
 
 
 ___
 HCP-Users mailing list
 HCP-Users@humanconnectome.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.humanconnectome.org_mailman_listinfo_hcp-2Dusersd=AAIGaQc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=3I6-yvEg8KFim9hIErhCvm3QH8yehzFWJ6HsWQoeUT8m=UEyeqf3jP4WJpWQN5X0VinWErEJz5X0LwGv9I9bKTaEs=VGju-usV7cI7ZgqageB_YKPSrZ9SFw22f0BHVq4UfxAe=
  


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

Re: [HCP-Users] Diffusion data b values

[Xu, Junqian]

Ariel,

We recommend people to use these calculated b-values (including cross-terms) 
instead of the input b-values. This was explained explicitly at page 137, 2nd 
paragraph in

http://www.ncbi.nlm.nih.gov/pubmed/23702418

Small b value variations due to the cross-terms between diffusion and imaging 
gradients are calculated (vendor supplied algorithm) in units of 5 s/mm2 before 
the gradient nonlinearity correction

Regards
Gordon

On Aug 5, 2013, at 4:46 PM, Ariel Rokem aro...@gmail.com
 wrote:

 Hello everyone, 
 
 First of all, thanks for all the hard work on putting this data-set together. 
 I have been looking at some of the diffusion data and it's been a good 
 experience so far. 
 
 I have a question concerning the encoding of b values in this data set. 
 Nominally, data was collected in 3 different shells (1000, 2000 and 3000 
 s/mm^2), but the values encoded in the files are not exactly these three 
 values. That is, values are +/- 5-10 units from these three shells (and from 
 0). As in:995, 990, 1005, 3005, 5, etc. 
 
 Should we take these values literally? Was there a difference in the 
 diffusion encoding between these different directions? If so, why? 
 
 Another related question: I recall a talk (at ISMRM?) in which one of the 
 researchers affiliated with HCP mentioned fluctuations of b value across the 
 volume (I apologize not remembering who this was...). Does anyone have a good 
 reference about these fluctuations, for this data, or other data? 
 
 Thanks again for your help with this question and for all the work on this, 
 
 Ariel Rokem
 Department of Psychology
 Stanford University
 ___
 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