Store n_cycles
and time_bandwidth
params in *TFR
objects #12851
Description
Describe the new feature or enhancement
Discussed partly with @larsoner.
MNE-Connectivity is being updated to allow connectivity computations using complex coefficients stored in EpochsTFR
objects (mne-tools/mne-connectivity#232). For the multitaper method, TFR coefficients have a tapers dimension that need to be aggregated over when computing the CSD. These weights are not stored in the *TFR
objects, and computing these weights requires knowledge of the time_bandwidth
and n_cycles
used to estimate the TFR. However, currently these parameters are not stored in *TFR
objects.
If we want to accurately compute these weights in MNE-Connectivity, we would currently require the user to pass these parameters in addition to the EpochsTFR
object. It would be more convenient if this information could also be read from the EpochsTFR
object.
Describe your proposed implementation
There were two ideas:
- Either store this information directly as attributes, e.g.,
tfr.n_cycles
andtfr.time_bandwidth
- Or store these params as a dict to minimise clutter in the
*TFR
namespace, e.g.,tfr.estimation_parameters = {'mt_bandwidth': 4, 'n_cycles': 5}
Describe possible alternatives
An alternative would be to just store the taper weights in the *TFR
objects, which is similar to how this is now handled for *Spectrum
objects. However, the weights are not returned by tfr_array_multitaper
, so they would still need to be recomputed.
It's perhaps simpler if we just handle this in MNE-Connectivity using the stored estimation params.
What do people think is the best choice?