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]<mailto:[email protected]>> on behalf of Andrew Poppe <[email protected]<mailto:[email protected]>> Date: Friday, January 27, 2017 at 12:58 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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<http://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]<mailto:[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
