Add process to cluster channels based on their proximity to cortical ROI

[Edouard2laire]

This process allows for automatic clustering of channels based on their distance to the ROI on the cortex.

The clustering can be performed either based on Euclidean distance or sensitivity. When using sensitivity, we attribute, for each channel, the ROI with the most sensitivity.

Note: Is there an easy way to visualize only channels from a specific cluster? Or to visualize how the channels are in different clusters on the scalp?

Note 2: I only tested for NIRS, but this should work fine for EEG/MEG.

Note 3: I believe this also satisfies the following request in the to-do list:

Create clusters from anatomical labels (Anne So) :
Identify contacts in a given anatomical region (volume scout, surface mesh, or label in a volume atlas) / allow extracting the signals from all the contacts in an ROI> As a process to select recordings, then Scouts from Volume Atlas, Create cluster in channel file, then Extract time series.

Process:

[tmedani]

Hi @Edouard2laire ,

Thank you again for the PR and for pushing this forward.
We discussed the channel clustering feature in detail during our last meeting, especially regarding its applicability across modalities.

Overall, we agree that the approach makes sense and can be useful, particularly for fNIRS applications. In the fNIRS case, clustering channels based on sensitivity and ROI proximity is conceptually consistent with how the modality samples cortical regions, and we think this can be a valuable addition for users working in that framework.
However, for EEG and MEG, we have some concerns. The sensitivity profiles of these modalities are fundamentally different and strongly dependent on the head model, montage, and sensor geometry. Assigning ROIs or clustering sensors based on simplified sensitivity assumptions could be misleading for many users.
In particular, unlike fNIRS, EEG/MEG lead fields are spatially complex and do not map cleanly to nearest-region assumptions. We want to avoid encouraging interpretations that may not be physiologically well-grounded.
For that reason, we propose to:

• Limit this feature to fNIRS for now.
• Clearly indicate in the documentation and interface that it is intended for fNIRS sensitivity-based analysis.
• Keep the door open to future extensions (e.g., EEG or stimulation contexts) once we further evaluate the methodological implications for EEG/MEG.

Additionally, since this would be restricted to fNIRS, we are wondering whether it might make more sense for this functionality to be integrated within NIRSTORM rather than the main Brainstorm pipeline.
We would be interested in your thoughts on this point?

We also plan to run additional tests on different scenarios to better characterize its utility and possible application cases.
Thanks again for the contribution, we believe the underlying idea has merit, and with a scoped implementation it can be a strong addition to Brainstorm.
Best,
Takfarinas

[Edouard2laire]

Hi @Edouard2laire ,

Hi :)

In particular, unlike fNIRS, EEG/MEG lead fields are spatially complex and do not map cleanly to nearest-region assumptions.

Thanks a lot for the review. I agree that using distance only to cluster the channels would be misleading for EEG and MEG, as the sensitivity profiles of these modalities are fundamentally different and strongly dependent on the head model, montage, and sensor geometry. That's why this PR is also proposing to create the cluster based on the sensitivity map: attributing, for each channel, the ROI for which it has the maximal sensitivity (as estimated by the EEG/MEG forward model).

But I agree that it might be difficult to attribute a single region to each sensor if the leadfield spans multiple regions.

We want to avoid encouraging interpretations that may not be physiologically well-grounded. For that reason, we propose to:

• Limit this feature to fNIRS for now.
• Clearly indicate in the documentation and interface that it is intended for fNIRS sensitivity-based analysis.
• Keep the door open to future extensions (e.g., EEG or stimulation contexts) once we further evaluate the methodological implications for EEG/MEG.

I think this is a good idea. We can even put the process under the NIRS tab for now.

Additionally, since this would be restricted to fNIRS, we are wondering whether it might make more sense for this functionality to be integrated within NIRSTORM rather than the main Brainstorm pipeline. We would be interested in your thoughts on this point?

I have no objection to this. I prefer to have the process in Brainstorm with a limitation so it works only for NIRS. The reason is that if we move the process to NIRSTORM, then, if a similar process is included in Brainstorm in the future, it will create a duplicate (2 different processes doing the same thing), which might confuse NIRS users.

[rcassani]

Thanks @tmedani for the detailed review. I agree with it on the potential confusion that would be introduced for EEG and MEG.

I have no objection to this. I prefer to have the process in Brainstorm with a limitation so it works only for NIRS. The reason is that if we move the process to NIRSTORM, then, if a similar process is included in Brainstorm in the future, it will create a duplicate (2 different processes doing the same thing), which might confuse NIRS users.

@Edouard2laire, since the process will be only for NIRS, it does make sense to make it part of NIRSTORM. A similar process is not likely to be included in Brainstorm at least for EEG and MEG due to limitations and potential misleading explained by Takfarinas. If you want, I can give it a review once the PR for NIRSTORM is ready.

[Edouard2laire]

Closing. Transfered to nirstorm: Nirstorm/nirstorm#302 :)