[Mne_analysis] mne report command

Alexandre Gramfort alexandre.gramfort at telecom-paristech.fr
Fri Jul 11 14:34:44 EDT 2014
Search archives:


> By default don't include events with value of 0 (maybe include it as
> an option). In most cases these are not true events.

the events are actually 1 not 0. This remark suggests me that we
should not use standard y ticks/scaling for plot_events

> The covariance matrix scaling for gradiometers in the sample file seems flat.

I this it's correct. It's empty room with SSP applied.

> At least an option to force a scaling factor for each file type
> (because it can be confusing for example that the left and right
> visual evoked examples have different scalings for the gradiometers).
> It would be most helpful to split the Trans plot into multiple plots.
> One with just the outer_skin (opaque) and array (transparent) (I would
> prefer a sagittal view perhaps a view from the front is helpful too).
> Another one to five plots (multiple angles) of the outer skin
> (transparent) with the digitized points (scaled to indicate distance
> from the surface).

we can indeed do better. Maybe you can take a look at the plot_trans
function and improve it a bit?

> Paring down the amount of information shown in the Raw examples would
> be helpful.


> I would also like to see a set order to the file (preferably based on
> a default flow for example: raw, -ave, -cov, trans, fwd, inv).

good point. +1

> I would love to see the -eve file information included in the
> information with the raw information (in the same section). (even in
> cases where there is no -eve file (as find events can get this)).

I like this too.

> I'd also like to see some of the names changed to make a better
> association with the actual filenames/filenaming conventions (this may
> prove to be controversial). For example Evoked -> Average (these are
> -ave.fif). Instead of MRI at the top right (maybe BEM).

I suggested Evoked and MRI :) reason is that MRI can be displayed
without BEM and Evoked can contain other things than average (std dev
for example).

> But I would be happy to use this as is. It looks very good!


again really nice job Mainak.

thanks heaps Dan for the valuable feedback.


More information about the Mne_analysis mailing list