When computing the PSD of a simulated signal (20s of 2 KHz), @Marc.Lalancette and I noticed discrepancies in the overall power at certain frequencies depending on the window length (see image attached). Differing window lengths also appear to impact estimates of aperiodic exponent (with respect to FOOOF). I have been investigating a similar issue in early renditions of a time-resolved FOOOF, which you can imagine would be very sensitive to these forms of discrepancies in power spectra. @Marc.Lalancette suggested that this might be related to the windowing approach used in Brainstorm's PSD function (which I have also adopted in my time-resolved FOOOF), but if it turns out to be something else related to the approach for computing/estimating the PSD, please keep me posted. Data is also available if needed.
Other useful settings:
Overlap: 50%
Units: Physical
This is very normal and predictable when computing the PSD using the Welch method (as employed in this code). Please check the following link (Part: Estimating PSD with the Welch method) to find out the reason for this observation.
So the code is okay and nothing wrong with your results. There are other ways of filtering like Wavelet filters which tune the window length for different frequency bands.
@Luc, can you double-check that you have the latest Brainstorm and that you're using the 'physical' normalization everywhere? Can you also confirm that the figure above was not using the exact same data for the 2 different windows? I think you mentioned your peaks were taking into account the power of the aperiodic, so that might explain why the peaks look ok.
Hi @hossein27en, could you clarify what you mean? The post you linked does not explain the scaling difference. In fact, I corrected the normalization that was previously done in Brainstorm to remove this window-length-dependent scaling. When computing the physical power density (units^2/Hz), the window length changes the spectrum bin size, but this is accounted for when converting to power per Hz.
I was using a version of Brainstorm from late November 2020, but I have just installed and rerun the same process on the Jan 25 build. The results are the exact same as the figure I first included, so this effect is not related to the bug fix in October.
Both PSDs were generated using the same data. I also only have the option of using 'physical' normalization, so I am certain that this is the normalization process used for both PSDs. The process I am using to simulate the peaks is to scale their heights according to the aperiodic power at each specific frequency. It is complicated to explain in simple terms but this is mimicking the NeuroDSP's sim_peak_oscillation function (although I think this detail is far enough removed from the effect observed in the PSDs to be irrelevant).
I feel it is important to add to this thread that this issue does not appear to be happening when I compute the PSD using different window lengths for real data, but only for simulated data (through NeuroDSP for peaks).
I think I've partly understood this effect. Any comments or corrections are welcome!
It is due to the choice of the window function, in this case Hamming. The effect is present with windows that do not go to zero at the edges, but disappears with Hann, Blackman or Tukey windows for example. Intuitively, the discontinuity in the windowed data (when considered periodic) is similar to a sawtooth wave and leads to broadband power. By using a wider window, the period of the wave is increased, which spaces out the harmonics and generally decreases the power per Hz.
I think we can also visualize this with respect to the Fourier transform of the windows themselves (e.g. Wikipedia) and spectral leakage. In general, windows with a discontinuity will have slow roll-off in the side lobes, which I guess explains why in this example we can see the leakage everywhere (at frequencies above the peaks) because it has higher amplitude than the 1/f^2 noise background. And increasing the window width "compresses" the window FT around the peak frequency, which reduces the leakage at a given (non-peak) frequency. So I think the effect would also happen with Hann, but it's hidden below the noise background because of the rapid roll-off.
So short solution: use a window with rapid roll-off, one that goes to zero at the edges. Hann, Blackman and Tukey are already implemented in Brainstorm, but we need to add the window function as an option in the PSD function/process.
Wow, I am impressed by 1) how you unpacked the issue and 2) the magnitude of the effect. From your report, should't we us a Hann window systematically then?
Perhaps. Given the nature of the brain spectrum, it makes sense to use a window with greater roll-off than the slope of the brain background/aperiodic component, at least when using FOOOF since we're interested in that component. However, the problem may not be as bad as this simulation data makes it look. Luc mentioned he did not observe the windowing effect with real data. I guess it depends on the relative amplitude of peaks vs the background. Still, is there any reason we would want to keep Hamming as the default other than compatibility?
At the very least, I think we need the option of choosing the window function.
