Discussion on Hilbert-Based Functional Connectivity Estimation and Edge Effect Artifacts

Discussions
1

Dear Brainstorm developers and community,

I have a question regarding the process of using the Hilbert transform to calculate functional connectivity metrics (such as wPLI, PLV) for epoched data in the Pipeline Editor, and I would like to ask for your insights. The details are as follows:

While following the functional connectivity tutorials, I found the connectivity module's GUI to be highly integrated, convenient, and excellent for reproducibility. However, when selecting Hilbert transform in the time-frequency decomposition and setting the time resolution to None (to calculate the static connectivity matrix), the software automatically performs band-pass filtering and the Hilbert transform at the bottom layer, and immediately compresses the time axis to output the final averaged matrix. This makes it impossible to crop out the head and tail edge effects caused by filtering within the GUI when processing short-segment resting-state data (such as 2-second or 10-second epochs). Therefore, my question is, will this affect the accuracy of the functional connectivity metrics? If there is an impact, is there a solution?

Initially, I wanted to proceed step-by-step, which means performing the Hilbert transform first, then cropping the head and tail edge effects through the extract time option, and then performing the functional connectivity metric calculation, but this seems impossible to achieve. Therefore, the method I am currently considering is to directly use the un-epoched or concatenated continuous resting-state data, use the windowed option in time resolution, set the time window length to the desired epoch length, and set the time window overlap to 0%. I wonder if this is acceptable? Or is there a more effective processing method?

In addition, even if this method is feasible, it seems it can only be used for resting-state data and cannot be used for task-state data.

I would be extremely grateful for any guidance or recommendations you could provide. Thank you very much for your time and help!

Best regards,

Deyu Li.

connectivity
connectivity450×499 15.6 KB

Lagged Coherence: What if window too short?
2

Hi @DeyuLi, Thank you for the detailed DSP question! Indeed, it's great to see that level of in the implementation of bst_connectivity.m. Here some comments to the raised questions:

This is correct, for the moment data in the transition is kept in the computation. The impact of this on your data depends on the percentage of samples that this transition segment represents in comparison with the non-transition samples. In the past, we used to use mirror-padding of the signal to reduced the artifacts in the transition segment, this was removed in the 2023 update on the connectivity codes. Commit: 24e3d22

Right, this is not possible through the GUI, as the connectivity is performed on time-series data, not on complex time-frequency data.

This will give you a time-resolved PLV (rather than static value a with the option none), moreover, the transition segment will have an impact in the PLV estimates of the first and last time windows. Moreover, going from the time-windowed PLV to the static is NOT done by averaging the PLV values in each window.

A better solution should be on the Brainstorm side to:

  1. Inform the length of the transition band in comparison with the length of the epoch, and show a warning accordingly

  2. Ignore the transition band on the computation of PLV (and other coherence/phase metrics)

  3. Add back mirror padding an option (?) No

FYI @Marc.Lalancette

3

Hi Raymundo,

Thank you very much for your professional advice and explanations, which have greatly helped clear up my doubts.

I would also like to take this opportunity to express my sincere respect and gratitude for the wonderful work that you and the Brainstorm team have done.

Best regards,

Deyu Li

4

Added in e8152d09

1 Like