Thank you for the quick reply! So you would recommend adding the mean image for both dense and parcellated analyses? Our task runs are 718 volumes each with a TR of 0.72 seconds.
Thanks again, Andrew Poppe, Ph.D. Postdoctoral Fellow Olin Neuropsychiatry Research Center Institute of Living Hartford Hospital On Fri, Jan 27, 2017 at 3:00 PM, Glasser, Matthew <[email protected]> wrote: > It is correct that the taskfMRI pipeline requires the data to not be > demeaned and by default currently the ICA+FIX pipeline produces demeaned > data with recent versions of FSL because the mean is removed by the > highpass filter. It would be sufficient to compute the mean image from the > uncleaned data and add it to the cleaned data. If there are any other bugs > in the taskfMRI Pipeline that interact with ICA+FIX cleaned data, I will > know about them soon as I am doing similar processing. How long are your > task fMRI runs? > > Peace, > > Matt. > > From: <[email protected]> on behalf of Andrew Poppe < > [email protected]> > Date: Friday, January 27, 2017 at 12:58 PM > To: "[email protected]" <[email protected]> > Subject: [HCP-Users] Problem using FIX clean data in parcellated stats > pipeline > > Howdy HCP folks, > > We've recently run into a problem when attempting to use ICA+FIX cleaned > data in a parcellated stats analysis pipeline. I'll run through what we've > done, what happened, and what I think is going wrong. Hopefully you can > provide some insight into if we've done things correctly and if so, what to > do about it. > > We are using the IcaFixProcessingBatch.sh script to apply ICA+FIX to our > data using the provided HCP_hp2000.RData training data, following the > application of GenericfMRIVolumeProcessingPipelineBatch.sh and > GenericfMRISurfaceProcessingPipelineBatch.sh. > > This produces a file with a name ending in _Atlas_hp2000_clean. > dtseries.nii. > > Previously, before attempting to use ICA+FIX, we have successfully used > the TaskfMRIAnalysisBatch.sh script to run a parcellated analysis. In order > to use ICA+FIX results as our input data, I changed the name of the clean > data to be ${TASK}_Atlas.dtseries.nii to "trick" the batch script to use > the cleaned data instead of the original data. > > This worked fine when doing a dense analysis, but the analysis failed when > trying to run a parcellated analysis. > > Specifically, when examining the logs of the analysis, the output of > film_gls included the line: *numTS=0* when using FIX cleaned data when it > had been *numTS=360* when using the original data. > > The film_gls code appears to do some masking of non-brain voxels toward > the beginning, and this masking process effectively zeroed out all values > in the FIX cleaned data whereas it allowed all values to remain when using > original data. Looking at the FAKENIFTI files produced from the original > data compared with ICA+FIX cleaned data, it seems the ranges are quite > different. > > For the original data (for a representative subject), the mean value of > the FAKENIFTI was around 11000 (range was ~5000 to ~15000). For the FIX > cleaned data, the mean was effectively zero (range was -420 to 382). > > During the masking procedure in film_gls, a "mask" is produced by > averaging voxel values across time. Next, that mask is binarized based on a > user-supplied threshold value. The default threshold value supplied to > film_gls in the TaskfMRIAnalysis pipeline scripts is 1. In the case of the > original data, all values in the mask are set to 1 since the range of this > mean mask volume is 6346.99 to 14440.96. However, for the mean mask created > from the FIX cleaned data, the range is -2.638159e-06 to 1.118895e-06, > such that binarizing with a threshold of 1 sets all values to 0. > > If I understand this correctly, it seems that this masking procedure > within film_gls is unnecessary during a parcellated analysis, because we > already know that there are no "non-brain" values to get rid of. So, I have > a couple questions about this: > > 1) Do the values for the ICA+FIX cleaned data I presented seem > representative of FIX results in your experience? Meaning, instead of a > mean around 10000 the data have a zero mean with a greatly reduced range. > Also, when taking an average across time, is it common to see effectively > zero values for all parcels? > > 2) If the answer to #1 is "yes," would it be okay to circumvent this > masking process within film_gls? I could imagine altering the pipeline > script to instead of providing a 1 for the threshold, provide the minimum > voxel value in the FAKENIFTI instead, insuring that the binarizing > procedure created a mask of all 1s. > > Any help or insight would be greatly appreciated, and please let me know > if you need more information. The relevant parts of the film_gls.cc code > are: > > read_volume4D(input_data,globalopts.inputDataName.value()); > reference=input_data[int(input_data.tsize()/2)-1]; > copybasicproperties(input_data,reference); > mask=meanvol(input_data); > variance=variancevol(input_data); > input_data-=mask; > mask.binarise(globalopts.thresh.value(),mask.max()+1,exclusive); > variance.binarise(1e-10,variance.max()+1,exclusive); //variance > mask needed if thresh is -ve to remove background voxels (0 variance) > mask*=variance; //convolved mask ensures that only super-threshold > non-background voxels pass > datam=input_data.matrix(mask,labels); > > And the relevant call to film_gls comes in TaskfMRILevel1.v2.0.sh on line > 235: > > film_gls --rn=${FEATDir}/ParcellatedStats --in=${FEATDir}/${ > LevelOnefMRIName}_Atlas"$TemporalFilterString""$ > SmoothingString"${RegString}${ParcellationString}_FAKENIFTI.nii.gz > --pd="$DesignMatrix" --con=${DesignContrasts} --fcon=${DesignfContrasts} > --thr=1 --mode=volumetric > > > Cheers, > > Andrew Poppe, Ph.D. > Postdoctoral Fellow > Olin Neuropsychiatry Research Center > Institute of Living > Hartford Hospital > > _______________________________________________ > 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. > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
