Baseline-correction for source estimates

[olafhauk]

Describe the problem

Baseline-correction for source estimates is recommended/necessary for some processing steps. For example, for unsigned source estimates, differences in noise levels may result in differences in intensities (e.g. for conditions with very different numbers of trials). This can be compenstated for by baseline-correction.

Describe your solution

Add a method 'baseline" to mne.SourceEstimate, equivalent to other structures (Evoked etc.).

Describe possible alternatives

Add a function such as mne.baseline_correct_stc().

Additional context

In my view the problem of different noise levels or numbers of trials for conventional source space analysis has not been highlighted enough. A while back we discussed this problem for RMS analyses of gradiometer data (https://imaging.mrc-cbu.cam.ac.uk/meg/SensorSpm, section "A note on gradiometer RMS").

[agramfort]

would you just do a DC offset or a z-score?

DC will not fix the scaling issue

[olafhauk]

This would not address my problem, and I don't understand the scaling issue (at least not specific to source estimates). The same logic as for evoked responses (e.g. when RMS or power are calculated) applies in source space: If noise is additive (which we usually assume also for baseline-correction in evoked or time-frequency data), you can reduce its bias by subtracting the mean of the baseline. I think this would be a useful feature - but of course it wouldn't have to be applied by default (and I cannot see any downside).

[agramfort]

we can add an stc.apply_baseline method but we need to be aware that will not keep provenance of this step in the stc files.

I can live with that

[hoechenberger]

Hm, I thought this had been discussed a couple of years ago, and it was decided that it might not be the best idea to have this: https://github.com/mne-tools/mne-python/issues/962

[agramfort]

@olafhauk can you have a look at discussion in https://github.com/mne-tools/mne-python/issues/962 ?

[olafhauk]

I agree that baseline-correction is not recommended for noise-normalised estimates, because additivity is obviously not valid for ratios anymore. Baseline-corrections also does not remove slow drifts.

However, in my view BC is recommended for unsigned activity estimates, because the mean of rectified signals is biased by their noise levels (as e.g. for power/RMS in signal space). Comparing unsigned source estimates with different noise levels (e.g. due to different numbers of trials) may lead to spurious effects, which can reduced by baseline-correction. This only works perfectly if noise and signal are additive, which is certainly not 100% the case (especially not for long epochs).

This is ultimately up to the user. I would use this method, but it would not have to be active by default, and its documentation should discuss the pros and cons.

[agramfort]

so you would suggest to use it with free orientation and method='MNE' but discourage it with dSPM or sLORETA?

[olafhauk]

Yes - only method='MNE'. It could be useful for all orientation options, but recommended for unsigned estimates. Looking at appy_inverse() now, is it possible to compute unsigned estimates for fixed orientations? I'll have to think about beamformers (should be the same logic as long as they are estimating intensities, not variances or SNRs). What about a function mne.source_estimate.correct_baseline() that users cannot apply by accident?

[agramfort]

Yes - only method='MNE'. It could be useful for all orientation options, but recommended for unsigned estimates. Looking at appy_inverse() now, is it possible to compute unsigned estimates for fixed orientations?

you can do stc.abs() to get unsigned from signed.

I'll have to think about beamformers (should be the same logic as long as they are estimating intensities, not variances or SNRs). What about a function mne.source_estimate.correct_baseline() that users cannot apply by accident?

stc.apply_baseline method would be more natural with a clear docstring

[hoechenberger]

stc.apply_baseline method would be more natural with a clear docstring

+1

[olafhauk]

Should I have a go?

[agramfort]

ok for me

[hoechenberger]

Closed via #8452