 |
 |
Hi AB, Ok, what I think you should do: 1. In your FEAT preprocessing, you should enable motion correction as well as including the motion parameter estimates in the design. 2. Once you have your two res4d files, you must make sure that they are registered to each other before concatenating them. The simplest way of doing this is to estimate a transformation from the example_func of one session (session A) to the example_func of the other session (session B). Use a 6 degree-of-freedom linear transformation with flirt, and then apply the transformation to the session A res4d file. After you have done this, you can concatenate them together. 3. It may be worth adding the session B example_func image to the concatenated res4d file before passing it to Melodic, as I suggested previously. This will ensure that the background images in the Melodic report are meaningful. Cheers, Paul On 20 November 2015 at 14:45, AR Bala <[log in to unmask]> wrote: > Hi Paul, > > Originally, I had "mcFlirted" the concatenated resting state res4d image > (each run's res4d had been preprocessed and registered prior to > concatenation). I fed this mcFlirted image through the design file I sent > you earlier. I had also set registration to 1. > > The second time I ran the analysis, I input the concatenated res4d image > without motion correction (since, as Anderson rightly pointed out- these > were already accounted for in the GLM and it was therefore not advisable to > motion correct again). I also set registration to 0. > > However, I now notice these "blue" activations (image attached in a > previous email on this thread) in almost all the participants in my > dataset. When I did set the motion correction parameter to 1 (just to > experiment with the data!), these blue activations were markedly reduced, > at least in the one subject that I ran it on. > > Please let me know if there's any other information you'd like me to > provide you with. > > Thank you very much for your help, > AB > > > On Fri, Nov 20, 2015 at 8:15 AM, paul mccarthy <[log in to unmask]> > wrote: > >> Hi AB, >> >> Could you please clarify how your preprocessing regime has changed from >> that specified in the original email (the one which was answered by >> Anderson)? >> >> Cheers, >> >> Paul >> >> On 19 November 2015 at 19:55, AR Bala <[log in to unmask]> wrote: >> >>> To add to this: >>> >>> The ICAs are now being classified so that they account for nearly 100% >>> variability (99.999%.....) >>> >>> On Thu, Nov 19, 2015 at 11:29 AM, AR Bala <[log in to unmask]> >>> wrote: >>> >>>> Hi Paul, >>>> >>>> Apologies for getting back to you so late. It was the same design file. >>>> I realized that I may have interrupted the process by constantly checking >>>> the ICA report generated in the log file. Once I let it run on its own, >>>> everything went on fine (the only thing I changed in the design file the >>>> second time around was setting the background image to 5 as opposed to 3). >>>> >>>> That said, my images do look a little off, in the sense that there are >>>> several areas of "underactivation" that I am finding hard to interpret >>>> (across all ICA components now-generated). I've attached a snapshot of one >>>> ICA component for your perusal. >>>> >>>> Per some lit search, the temporal course for most of the ICA components >>>> (for e.g. for the component attached) seem to suggest head motion artifacts >>>> (despite correcting for these during the preprocessing stage of each RS >>>> scan). Should I set the motion correction flag to 1, in the dummy >>>> melodic.fsf? >>>> >>>> Thank you for your help. >>>> >>>> Thanks, >>>> AB >>>> >>>> On Thu, Nov 19, 2015 at 11:16 AM, AR Bala <[log in to unmask]> >>>> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Apologies for getting back to you so late. It was the same design >>>>> file. I realized that I may have interrupted the process by constantly >>>>> checking the ICA report generated in the log file. Once I let it run on its >>>>> own, everything went on fine (the only thing I changed in the design file >>>>> the second time around was setting the background image to 5 as opposed to >>>>> 3; the design file is attached). >>>>> >>>>> That said, my images do look a little off, in the sense that there are >>>>> several areas of "underactivation" that I am finding hard to interpret (I >>>>> am working with data from a TBI sample; first-level). I've attached a >>>>> snapshot of one ICA component for your perusal. >>>>> >>>>> Per some lit search, the temporal course for most of the ICA >>>>> components (for e.g. for the component attached) seem to suggest head >>>>> motion artifacts (despite correcting for these during the preprocessing >>>>> stage of each RS scan). Should I set the motion correction flag to 1, in >>>>> the dummy melodic.fsf? >>>>> >>>>> Thank you for your help, >>>>> AB >>>>> >>>>> >>>>> On Thu, Nov 19, 2015 at 10:58 AM, AR Bala <[log in to unmask]> >>>>> wrote: >>>>> >>>>>> Hi Paul, >>>>>> >>>>>> Apologies for getting back to you so late. It was the same design >>>>>> file. I realized that I may have interrupted the process by constantly >>>>>> checking the ICA report generated in the log file. Once I let it run on its >>>>>> own, everything went on fine. >>>>>> >>>>>> That said, my images do look a little off, in the sense that there >>>>>> are several areas of "underactivation" that I am finding hard to interpret >>>>>> (I am working with data from a TBI sample; first-level). I've attached a >>>>>> pdf of the report log for your perusal. >>>>>> >>>>>> Per some lit search, the temporal course for most of the ICA >>>>>> components (for e.g. in the pdf attached)seem to suggest head motion >>>>>> artifacts (despite correcting for these during the preprocessing stage of >>>>>> each RS scan). Should I set the motion correction flag to 1, in the dummy >>>>>> melodic.fsf (for your convenience, I have reattached the design file)? >>>>>> >>>>>> Thank you for your help, >>>>>> AB >>>>>> >>>>>> On Thu, Nov 19, 2015 at 10:47 AM, AR Bala <[log in to unmask]> >>>>>> wrote: >>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> Apologies for getting back to you so late. It was the same design >>>>>>> file. I realized that I may have interrupted the process by constantly >>>>>>> checking the ICA report generated in the log file. Once I let it run on its >>>>>>> own, everything went on fine. >>>>>>> >>>>>>> That said, my images do look a little off, in the sense that there >>>>>>> are several areas of "underactivation" that I am finding hard to interpret >>>>>>> (I am working with data from a TBI sample; first-level). I've attached a >>>>>>> pdf of the report log for your perusal. >>>>>>> >>>>>>> Per some lit search, the temporal course for most of the ICA >>>>>>> components (for e.g. in the pdf attached)seem to suggest head motion >>>>>>> artifacts (despite correcting for these during the preprocessing stage of >>>>>>> each RS scan). Should I set the motion correction flag to 1, in the dummy >>>>>>> melodic.fsf (for your convenience, I have reattached the design file)? >>>>>>> >>>>>>> Thank you for your help, >>>>>>> AB >>>>>>> >>>>>>> On Tue, Nov 17, 2015 at 4:31 AM, paul mccarthy < >>>>>>> [log in to unmask]> wrote: >>>>>>> >>>>>>>> Hi AB, >>>>>>>> >>>>>>>> Would you be able to send me the original design.fsf file as well >>>>>>>> (i.e. the one which generated valid components, but white background in the >>>>>>>> report)? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>> On 16 November 2015 at 18:41, AR Bala <[log in to unmask]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> To follow-up on this: For some reason, the ICA's no longer >>>>>>>>> converge (the log file below has "Registration to standard image" set to 1, >>>>>>>>> but it does not work even if it is set to 0). I've attached the design >>>>>>>>> file and log file. I'd be grateful for any directions towards resolving the >>>>>>>>> issue. >>>>>>>>> Thanks again, >>>>>>>>> AB >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 16, 2015 at 9:11 AM, AR Bala <[log in to unmask]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thank you very much Paul! That is exactly what happened - I'd >>>>>>>>>> used the 'mean functional' as the background image. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Nov 16, 2015 at 5:37 AM, paul mccarthy < >>>>>>>>>> [log in to unmask]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi AB, >>>>>>>>>>> >>>>>>>>>>> Did you select 'Mean functional' as the background image on the >>>>>>>>>>> Melodic GUI post-stats tab? If so, the all-white background is probably due >>>>>>>>>>> to the fact that all of the individual voxels within a residual image are >>>>>>>>>>> de-meaned. >>>>>>>>>>> >>>>>>>>>>> You can either choose a different background image (structural >>>>>>>>>>> or standard). Or, if you really want the functional data as your >>>>>>>>>>> background, you could add the mean of the original data to your res4d image >>>>>>>>>>> before running Melodic. This will make your data 'look' more like a >>>>>>>>>>> functinoal image, but won't change the melodic results. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> On 15 November 2015 at 16:59, Ar B <[log in to unmask]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello all, >>>>>>>>>>>> >>>>>>>>>>>> I've concatenated 2 resting state res4d scans, and tried to run >>>>>>>>>>>> MELODIC on the concatenated registered res4d data (because I had already >>>>>>>>>>>> done registration, I set all registrations for the melodic.fsf design file >>>>>>>>>>>> to 0, also taking note of the comments in this thread: >>>>>>>>>>>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1511&L=fsl&F=&S=&X=405BDF168924D4B110&Y=arb.edqueries%40gmail.com&P=200122 >>>>>>>>>>>> >>>>>>>>>>>> I am able to generate components without errors, but on viewing >>>>>>>>>>>> the ICs, I see the images as completely white (sample component slices >>>>>>>>>>>> screenshot attached). I do see areas of activation that are interpretable, >>>>>>>>>>>> but why is it that the ventricles and other "dark" areas that should be >>>>>>>>>>>> present in the image aren't seen? >>>>>>>>>>>> >>>>>>>>>>>> I appreciate all your help, and apologize if this should be >>>>>>>>>>>> obvious! >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> AB >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >