Thanks Michael, I will look into all of these over the next few days... Neither the first or second thing you suggested to check in the HCP scripts would've occurred to me. So those suggestions are greatly appreciated. The possibility that the HCP scripts somehow in their function assumes the phase encoding is the same sounds really possible. I didn't try to see if the listserv could post *.jpgs of the results I'm getting. But honestly, the funky result really looks like a fundamental mismatch of phase encoding setting. However, I know I've got things set correctly for the EPI data phase encoding direction. If the scripts are somehow doing the topup and applytop steps assuming both have the same phase encoding, that'd easily account for the wonky results. So I'll go digging for that first.
I'll paste the code splice in for the spatial resolution problem and let you know if I have any problems. Thanks again! Best, Mike From: Harms, Michael [mailto:mha...@wustl.edu] Sent: Monday, August 31, 2015 3:40 PM To: Stephen Smith; Stevens, Michael Cc: hcp-users@humanconnectome.org Subject: Re: [HCP-Users] TOPUP options with HCP scripts - Phase Encoding and Voxel Size incompatibilty with EPI Hi Michael, I know of at least one adaptation that you'll need, but your particular situation may unfortunately need more. Tthe issues at play involve a fairly complicated, dense section of code. Hopefully Matt can chime in if he is available. Your question involves the guts of the DistortionCorrectionAndEPIToT1wReg_FLIRTBBRAndFreeSurferBBRbased.sh and TopupPreprocessingAll.sh scripts. (The latter is called as part of the former). The relevant variables to try to keep track of initially are: DwellTime (--echospacing argument) and UnwarpDir. First, your changing resolution probably resulted in a least a somewhat different bandwidth, and thus echo spacing between your SpinEcho EPIs and your Gradient Echo BOLD fMRI scans. Based on a quick look, I can't tell if the echo spacing of the BOLD fMRI scan ever comes into the picture as part of the topup distortion correction. If not, just set the ES according to your SE scans. Second, you had a different phase encoding direction between the SE scans and the BOLD fMRI. That I think is a problem, because I think that TopupPreprocessingAll.sh assumes that the supplied UnwarpDir is the same for both the SE scans and the BOLD fMRI -- in terms of the registration between scout and SE scans, and also possibly in terms of what gets encoded in the WarpField output of topup. (Off the top of my head, I'm not sure if the WarpField is no longer dependent on the the UnwarpDir). Last, the resolution mismatch will cause a problem, but that one I've dealt with previously as part of helping someone else that also acquired the BOLD fMRI at a different resolution from the SE scans. For that, you can try the solution below. cheers, -MH -------- First, make a copy of the original TopupPreprocessingAll.sh in global/scripts e.g., cp TopupPreprocessingAll.sh TopupPreprocessingAll.sh.orig Then add the following line in red to the relevant section of the code in TopupPreprocessingAll.sh (should be around L260, but depending on the precise version you are using, may just be near L260): # Scout - warp and Jacobian modulate to get distortion corrected output ${FSLDIR}/bin/applywarp --rel --interp=spline -i ${WD}/SBRef.nii.gz -r ${WD}/SBRef.nii.gz -w ${WD}/WarpField.nii.gz -o ${WD}/SBRef_dc.nii.gz ${FSLDIR}/bin/applywarp --rel --interp=spline -i ${WD}/Jacobian.nii.gz -r ${WD}/SBRef_dc.nii.gz --premat=$FSLDIR/etc/flirtsch/ident.mat -o ${WD}/Jacobian.nii.gz ${FSLDIR}/bin/fslmaths ${WD}/SBRef_dc.nii.gz -mul ${WD}/Jacobian.nii.gz ${WD}/SBRef_dc_jac.nii.gz -- 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<mailto:mha...@wustl.edu> From: Stephen Smith <st...@fmrib.ox.ac.uk<mailto:st...@fmrib.ox.ac.uk>> Date: Monday, August 31, 2015 2:07 AM To: "Stevens, Michael" <michael.stev...@hhchealth.org<mailto:michael.stev...@hhchealth.org>> Cc: "hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org>" <hcp-users@humanconnectome.org<mailto:hcp-users@humanconnectome.org>> Subject: Re: [HCP-Users] TOPUP options with HCP scripts - Phase Encoding and Voxel Size incompatibilty with EPI Hi AFAIK you can - in theory - use the topup-derived B0-fieldmap to unwarp the fMRI-EPI data even with these differences in acquisition. However I can't comment at all on how much work it will be to adapt the HCP scripts to make this happen. Would need advice from others on that point. Cheers, Steve. On 30 Aug 2015, at 14:05, Stevens, Michael <michael.stev...@hhchealth.org<mailto:michael.stev...@hhchealth.org>> wrote: Hi folks, I have a technical question about processing data using the HCP 3.5 pipeline scripts. We recently set up an HCP MRI data collection protocol for one of my new R01s. I just learned over the weekend that - although we did a very careful job ensuring that all the sequences being used for the primary experimentation were correctly configured - we made one mistake. We added a resting state scan after the rest of it was set up and mistakenly pulled the wrong EPI sequence for it. As a result, the voxel sizes and phase encoding for resting state do not match the spin echo sequences we were planning to use for TOPUP unwarping of our other EPI data. Specifically, the spin echo sequences are L/R and R/L encoding at 2.1 mm isotropic resolution, while the EPI resting state data was collected using A/P at 3.0 mm isotropic. So, we can process the primary fMRI task data just fine. But, will it still be possible to process the resting state data using the HCP scripts and approach? We have to use TOPUP for distortion correction as we did not collect a gradient echo fieldmap scan. I had understood that TOPUP didn't really care that much as long as you could create a valid fieldmap. However, I've been primarily an SPM user for my MRI research until we started using the HCP approach a year ago. So my FSL knowledge remains comparatively limited and I just don't know. When I run the HCP scripts to try this out, the primary thing that seems to go wrong is it throws an error in from the TopupPreprocessingAll.sh script (line 251) when it tries to multiply the Scout by the Jacobian.nii.gz b/c they're different voxel sizes. Otherwise it runs through to the end (we've disabled Jacobian modulation option (so the OneStepResampling script never encountered the same problem). However, visual inspection of the results for one sample dataset doesn't look like the later processing stages got things exactly right... There's some odd distortions down near the OFC where you'd expect the most amount of unwarping to be done. I got to wondering whether there was a simple L/R vs A/P incompatibility, i.e, that this won't work at all. Or maybe more complicated... if the different voxel sizes between the fieldmap and EPI might've put the origins of the images at different places and ended up confusing the OneStepResampling step. Or something... I'm testing this on all these datasets now to see whether the results across multiple subjects look visually OK or not. But as I do this, it'd be great if someone could tell me a simple "Yes" or "No" if I'm wasting my time with this. Even if this is possible but it requires some modifications/recoding to the HCP scripts (e.g., to resample the fieldmaps to 3x3x3 resolution after they're calculated??). I'm happy to do the latter if someone lays out for me what changes might needed. Thanks, Mike Michael C. Stevens, Ph.D. Director, Clinical Neuroscience & Development Laboratory Director, Child & Adolescent Research, The Institute of Living Associate Professor of Psychiatry (Adjunct), Yale University School of Medicine This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message, including any attachments. _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org<mailto:HCP-Users@humanconnectome.org> http://lists.humanconnectome.org/mailman/listinfo/hcp-users --------------------------------------------------------------------------- Stephen M. Smith, Professor of Biomedical Engineering Head of Analysis, Oxford University FMRIB Centre FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK +44 (0) 1865 222726 (fax 222717) st...@fmrib.ox.ac.uk<mailto:st...@fmrib.ox.ac.uk> http://www.fmrib.ox.ac.uk/~steve --------------------------------------------------------------------------- Stop the cultural destruction of Tibet<http://smithinks.net> _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org<mailto: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
