Re: [HCP-Users] GenericfMRIVolumeProcessingPipelineBatch motion correction

[Glasser, Matthew]

Generally though the first few volumes will have more contrast and thereby may be a better registration target.  We can make the option on our end, thanks for the patch.   Peace, Matt. From: Julien Dubois <jcrdub...@gmail.com> Date: Tuesday, December 16, 2014 at 12:18 PM To: Matt Glasser <glass...@wusm.wustl.edu> Cc: Mark Jenkinson <mark.jenkin...@ndcn.ox.ac.uk>, "Harms, Michael" <mha...@wustl.edu>, "hcp-users@humanconnectome.org" <hcp-users@humanconnectome.org>, "Brown, Tim" <bro...@mir.wustl.edu> Subject: Re: FW: [HCP-Users] GenericfMRIVolumeProcessingPipelineBatch motion correction I may be confounding things, but since the first few volumes are usually discarded from analyses to allow for magnetization stabilization, I thought it may be better to use the mid-volume (and it is also the default in mcflirt). Besides, in mcflirt_acc you choose volumes 11-20 if no SBref is provided (which never actually happens since GenericfMRIVolumeProcessingPipeline sets a SBref), so that went along with my belief. However, magnetization equilibration may not have an important effect on gray-white matter contrast, so this may be very arbitrary. I'll defer to MR physicists here if they have input on the matter... Also, sorry I only provided a hack and not a full fledged option in GenericfMRIVolumeProcessingPipeline.  - Julien Julien Dubois Postdoctoral Scholar California Institute of Technology, Pasadena, CA http://www.emotion.caltech.edu/~jdubois On Tue, Dec 16, 2014 at 10:06 AM, Glasser, Matthew <glass...@wusm.wustl.edu> wrote: Hi Julien, Thanks for sending this in.  Why do you think the mid volume is better than the first volume? I’d like Mark to look over the mcflirt call and Mike to have a look as well.   Tim, we’ll want this to be set up as an optional argument to GenericfMRIVolumeProcessingPipeline.sh that defaults to mcflirt_acc (for now at least), but allows setting the pipeline to run mcflirt as well.   Thanks, Matt. From: Julien Dubois <jcrdub...@gmail.com> Date: Tuesday, December 16, 2014 at 11:51 AM To: Matt Glasser <glass...@wusm.wustl.edu> Cc: "hcp-users@humanconnectome.org" <hcp-users@humanconnectome.org> Subject: Re: [HCP-Users] GenericfMRIVolumeProcessingPipelineBatch motion correction Dear all, I have made changes to two files to make use of FSL's mcflirt instead of HCP's flirt-based mcflirt_acc: * in Pipelines/fMRIVolume : GenericfMRIVolumeProcessingPipeline.sh -> GenericfMRIVolumeProcessingPipeline_mcflirt.sh At line 121: I extract the midvolume as reference image when no SBref is provided (the previous behavior was to use the first volume, which may be problematic);   At line 159: I call MotionCorrection_MCFLIRTbased.sh instead of MotionCorrection_FLIRTbased.sh * in Pipelines/fMRIVolume/scripts: MotionCorrection_FLIRTbased.sh -> MotionCorrection_MCFLIRTbased.sh Motion correction is now done with mcflirt (see line 18 if you want to change parameters), and files are renamed and moved around to match the HCP pipeline So, with these two new files, all you have to do is call GenericfMRIVolumeProcessingPipeline_mcflirt.sh instead of  GenericfMRIVolumeProcessingPipeline.sh.  Hope this helps someone. - Julien   Julien Dubois Postdoctoral Scholar California Institute of Technology, Pasadena, CA http://www.emotion.caltech.edu/~jdubois On Sun, Dec 14, 2014 at 11:31 AM, Julien Dubois <jcrdub...@gmail.com> wrote: Thanks Matthew. My data is 2.5mm isotropic, slightly lower resolution than your 2mm isotropic but not exactly low res. I'm curious as to why you guys wrote your own mcflirt (seems like reinventing the wheel). Was FSL's mcflirt failing on HCP data? If no one else is working on a patch like you describe, I'll probably whip one up for my purposes so I'll keep you in the loop. - Julien > On Dec 14, 2014, at 12:45 PM, Glasser, Matthew <glass...@wusm.wustl.edu> wrote: > > Hi Julien, > > You are not the first to report this for lower resolution fMRI data. > We¹re not completely sure why the performance is different in these cases, > however we would definitely be interested in a patch for the fMRIVolume > pipeline that allowed choosing to use mcflirt instead of mcflirt_acc for > people who mcflirt_acc was not working correctly. > > Thanks, > > Matt. > >> On 12/14/14, 11:11 AM, "Julien Dubois" <jcrdub...@gmail.com> wrote: >> >> Sorry, ignore what I said for the aside: you take the average of 10 >> volumes starting at volume 11. Better than taking the first 10. Sorry for >> my Sunday early morning confusion :-) >> >> But the main issue remains, that mc flirt_acc does not correct for motion >> as well as mcflirt. Let me know your thoughts on why this may be. >> >> Thanks, >> - Julien >> >> >> >>> On Dec 14, 2014, at 10:14 AM, Julien Dubois <jdub...@caltech.edu> wrote: >>> >>> Dear all, >>> >>> I want to weigh in here: the current default behavior of the pipeline >>> is not doing a good job at motion correction (in my own data). >>> >>> First a quick digression: >>> The code in global/mcflirt_acc.sh indicates that you are taking the >>> 10th volume as a reference, in the absence of a supplied reference: >>> line 29: >>> ${FSLDIR}/bin/fslroi $input ${output}_ref 10 10 >>> I think that maybe you meant to take the average of the first 10 >>> volumes (as Greg B. indicated, and given the following lines of code); >>> so line 29 should likely be changed into: >>> ${FSLDIR}/bin/fslroi $input ${output}_ref 0 10 >>> >>> But I don't think this is where the issue comes from. Indeed, running >>> mcflirt with the 10th volume gives a fine result. There is thus >>> something else in mcflirt_acc that is not functioning properly (at least >>> for data other than HCP), compared to the standard FSL's mcflirt. >>> >>> Can you give the rationale for writing your own mcflirt function >>> (mcflirt_acc.sh), and explain how it differs from FSL's mcflirt? (I >>> could also go compare with the source code for mcflirt, but I thought I >>> would ask directly since you probably had a good reason) >>> >>> Thanks! >>> - Julien >>> >> >> _______________________________________________ >> 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.   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, 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