Noise covariance unused in the LCMV beamformer?

Hi everyone,

I have a question about the Brainstorm implementation of the LCMV beamformer that I'm hoping perhaps @John_Mosher or others might be able to clarify.

It appears that the noise covariance (e.g., derived from an empty room) may not be taken into account in the beamformer computation - is this correct? I've tried swapping noise covariance matrices between files, and the source images and kernel appear to be identical.

In "Tutorial 22: Source estimation -> Advanced options: LCMV beamformer", there appears to be conflicting information. In the opening paragraph it is stated that "...on top of the noise covariance matrix, you need to estimate a data covariance matrix in order to enable the option 'LCMV beamformer' in the interface", which I have found to be true. However, just below it also states that the PNAI is modified "to rely strictly on the data covariance, without need for a separate noise covariance matrix" and that regularization is only applied to the data covariance matrix.

In looking at the code (bst_inverse_linear_2018.m) I also see many indications that this may be the case:

-line 466: "We only calculate the data covariance matrix for LCMV"
-line 1059-60: "in the lcmv case, we used the data covariance as the whitener for programming simplicity"

If the noise covariance is not necessary for the LCMV computation, why would it be necessary to enable this option in the source imaging menu? Or is it used somewhere in the computation that I am missing?

Thanks in advance for any guidance,

Hi Alex,

While I'm not very familiar with that code, I also had a look and agree with your observation. I wanted to check if maybe it was used to regularize the data cov matrix, but no, the same process is used with the data cov instead. On the other hand, looks like the function computes noise covariance regardless and wouldn't run if it was missing.

I guess the noise cov could still be used at some point to produce Z scores, but that's not in the inverse function.


Thanks for looking into this Marc - nice to have another set of eyes on it.

I agree that it's possible the noise covar matrices are being used somewhere else, but maybe unlikely as the source images are (at least by-eye) identical when using different noise data.

If the noise covar isn't being used, maybe the best option would be to remove the requirement to compute noise covar before running LCMV, and then edit the tutorials to clarify?


Hello Alex, others,

Yes, I'm the guilty party who asked Francois to include both in the interface. As of the Brainstorm 2018, we are only using the data covariance in our LCMV implementation. But, I'm on the hook to re-implement noise pre-whitening, before applying regularized data covariances.

The BST2018 variation did exceptionally well in a recent publication, in which we (several research developers) had a friendly competition to see who did what in their various forms:

Comparison of beamformer implementations for MEG source localization

BST2018 used a simple but elegant "trick" (but rigorous) in programming that simply replaces noise with data covariance, while holding the rest of the code fixed, as you may have surmised when digging through the code. This is mathematically rigorous, but it is more conventional to have separate code. As you'll note in the above article, however, we did quite well.

One of the strong issues that arose among us is how to condition deficient covariance matrices, particularly in the case of mixed sensors, where simple conditioning often suppresses important information. So I still have in my notes how to re-apply the noise covariance first, in order to improve the truncation or regularization of the whitened data covariance, rather than applying the methods directly to the data covariance. Still a work in progress.

  • John

Hi John,

Thanks for getting back to me! This information is very helpful.

It makes complete sense then why the noise covariance is required, but not used in the current implementation. Maybe a short-term solution is to have the code create a "dummy" noise matrix, if noise covariance is not found when attempting to compute the LCMV (i.e., until noise pre-whitening is implemented)?

I also agree that the current beamformer implementation does quite well - anecdotally I've found the source images to be very reasonable, and our recent preprint indicates that spectral derivatives from this approach are highly stable within sessions (

Thanks again for the helpful response!

1 Like

A minor update on this - I've edited the "LCMV beamformer" section of the "Source Estimation" tutorial to reflect our discussion here, and to recommend that an identity matrix is substituted for the noise covariance, if necessary, to enable the beamformer option in Brainstorm.


1 Like

Thanks for the update!

1 Like