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 <[email protected]> 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 <[email protected]> > Date: Tuesday, December 16, 2014 at 11:51 AM > To: Matt Glasser <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 <[email protected]> > 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 <[email protected]> >> 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" <[email protected]> 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 <[email protected]> >> 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 >> >> [email protected] >> >> 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. > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
