Would the following commands accomplish adding the mean of the non-clean data to each volume of the FIX cleaned data?
Original.dtseries.nii : non-cleaned dense data Clean.dtseries.nii : cleaned data wb_command -cifti-reduce Original.dtseries.nii MEAN MEAN.dscalar.nii wb_command -cifti-math "a+b" clean_plus_mean.dtseries.nii -var a Clean.dtseries.nii -var b MEAN.dscalar.nii -select 1 1 -repeat Is this correct? Is there a better way to do it? Thanks, Andrew Poppe, Ph.D. Postdoctoral Fellow Olin Neuropsychiatry Research Center Institute of Living Hartford Hospital On Fri, Jan 27, 2017 at 4:03 PM, Glasser, Matthew <[email protected]> wrote: > Right. That is decently long for task fMRI runs. We think that with > short runs it may be hard to get optimal results with ICA+FIX, but we are > working on solutions for this. > > Peace, > > Matt. > > From: Andrew Poppe <[email protected]> > Date: Friday, January 27, 2017 at 3:00 PM > To: Matt Glasser <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [HCP-Users] Problem using FIX clean data in parcellated > stats pipeline > > 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.dtserie >> s.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}/${LevelOnefMRI >> Name}_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. >> > > > ------------------------------ > > 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
