I am using 3dRSFC to calculate f/ALFF on rsfMRI data preprocessed with Pestica/Slomoco in the following way:
3dRSFC -input $slomoco -prefix RSFC -band 0.01 0.08 -mask striatum.nii.gz -overwrite[/center]
I have also calculated in DPABI v5.1 but the results are completely different.
Did I forget some other preprocessing before using 3dRSFC? Or is a different formula used? Has someone noticed a similar difference?
What processing has been done already? Or is the dataset raw?
Note that some detrending is ON by default in 3dRSFC:
-nodetrend = Skip the quadratic detrending of the input that
occurs before the FFT-based bandpassing.
++ You would only want to do this if the dataset
had been detrended already in some other program.
I guess its possible ALFF might be different due to a scaling factor (that should be uniform across the volume) but fALFF should be quite similar.
And what DPABI command are you using?
I have removed the first 5 volumes, have applied slice time correction, and have processed the data with Pestica/Slomoco (version 5) to correct for physiological cardiac and respiratory noise and motion. I have also normalized the data to MNI152 using FSL’s flirt and fnirt. For ALFF calculation in AFNI, I have not used the -nodetrend flag but I will definitely try that, thank you!
In DPABI, I have used the GUI of DPARSF 5.3 Advanced Edition. I have selected a blank template, loaded the same input as descriped above and have only selected “ALFF/fALFF Band (Hz): 0.01 ~ 0.08”.
I have looked into both codes (3dRSFC[/url] and DPABI’s [url=https://github.com/Chaogan-Yan/DPABI/blob/master/DPARSF/Subfunctions/y_alff_falff.m]y_alff_falff.m, version 6.1).
I think the relevant line in DPABI y_alff_falff.m is 139:
AllVolume(:,Segment) = 2*abs(fft(AllVolume(:,Segment)))/sampleLength;
with AllVolume being the reshaped to 2D, masked, detrended, and zero-padded 4D input time series (Segment is an option to separate data into junks to be more RAM memory friendly; can be ignored here)
and sampleLength being the number of time points.
Next, ALFF_2D is calculated as:
ALFF_2D = mean(AllVolume(idx_LowCutoff:idx_HighCutoff,:));
As I am not really familiar with C, I did not fully understand whether this method is different compared to 3dRSFC (and the relevant lines of code starting from line 725). Could you maybe explain that a bit more?
The voxelwise ALFF values are calculated with the following steps:
time series (detrended or not, chosen by user) → FFT
For the denominator of fALFF:
- go through positive harmonics from m= 1 (ignore baseline harmonic) to Nyquist, and sum the sqrt of power per frequency (that is, sum the amplitudes)
For ALFF and numerator of fALFF:
- go through harmonics from m= minimum index to maximum index of bandpass range, and sum the sqrt of power per frequency (that is, sum the amplitudes)
Scale ALFF by 2/sqrt(number of time points)—the factor of 2 comes from going through just the “positive” harmonics.
Re. the factor of 2 common to both methods: that is purely implementational, as each one is summing over half of the Fourier components (which is fine, because they are symmetric, for real input signals).
So, one difference is that the ALFF is scaled by sqrt(N) in 3dRSFC, where N is the number of time points in the time series, rather than by just N, as used in DPABI. Why do we use sqrt(N)? Because the original ALFF work by Zang et al calculated ALFF in a similar way as here:
time series → FFT → power spectrum → sqrt of power spectrum → sum over LFF range.
So, because the original derivation mentions calculating a power spectrum, where each coefficient is typically scaled by 1/N, we have:
sqrt( power/N) = sqrt(power)/sqrt(N).
The relation of time series, Fourier transforms and both power and amplitude series are presented in the Appendix here:
and the ALFF is shown in that Eq. 7—note that the notional range of components is over the full N harmonics (not just N/2), so no factor of 2 shows up there.
I don’t quite understand the ALFF_2D aspect in above-posted code.