This is likely a naive question, but I couldn't find much help for myself either in the manual or browsing the mne_analysis archives. So, if I understand correctly, in mne_analyze, the SNR estimate display window shows what the data is expected to be with the red line and then shows the mismatch between the actual data and expected data with the green line (so the high amplitude difference between the green and red lines is bad yes?). Fairly unanimously, all of my subjects start off with both lines hugging each other pretty tight, but on some of my participants, the green line rises pretty sharply towards the end of the epoch. My trial length is relatively long, but nothing absurd (about 1s). My question is, what factors go in to computing this mismatch? Is it something in the computation of the noise covariance matrix or the inverse solution that I can tweak parameters on to try and improve the apparent mismatch? Or does this just represent subjects that aren't able to stay still and end up fidgeting or blinking or something towards the end of the trial? Thanks for any help, and I am of course happy to supply any further info that would help answer my question.
to me you hit a problem I have seen a few times that the stats of the
baseline differs from the stats of the end of your epochs. As you
estimate the noise cov from baseline it generates what you describe.
A way around this I have seen working is to highpass the data and
don't do any extra baselining. The difficulty here is that you might
distort the ERP/ERF by highpass filtering.
So this strategy worked great, but it has caused me to run into a new problem that I wasn't sure if you'd be able to help me with. When I try to produce stc files then extract from label files made in mne_analyze from the data processed using the strategy below, the data appears to become shifted on the y-axis across my subjects. The shape of the waveform itself is fine and is what is to be expected, but they are all shifted up or down on the y-axis (e.g. some start at -2, -6, 4, etc.). This is not how they appear in mne_analyze and I am using dSPM values across the board, but when I extract the stc data from the label files in the matlab toolbox I encounter the problem. Thanks for any help.
Can you tell us exactly how the numbers differ? : click on a point get
the value in mne_analyze, then extract that same timepoint in matlab
get the value, and tell us what the difference is (for a few points).
Judging just from the y-axis is difficult.
Also, I think mne_analyze baseline corrects from -0.2 to 0 by default,
which might not happen in the MATLAB code. This could introduce a vertical
shift.
I'm trying to do what you asked, but I got a noobie question for you. Is there a way to either have mne_analyze display the average dspm value for a label you've drawn? Or vice versa, I'm having trouble matching up the vertex number from mne_analyze in matlab to directly compare the numerical values. When I use mne_read_stc_file in matlab, it shows 6360 vertices, but the vertex number I'm looking for from mne_analyze is much higher (I was trying to find vertex # 11967 for example). I tried just dropping the first digit, but that wasn't yielding a meaningful comparison. Am I approaching how to do this comparison all wrong? Sorry for the naivete
Thanks. So for the values I got from mne_analyze:
t(ms) dspm
133.2 2.40
153.6 2.23
185.9 1.43
219.9 2.72
and from matlab:
t(ms) dspm
133.2 3.0192
153.6 1.6635
185.9 .9090
219.9 2.6229
I would imagine that as Eric was getting at, it is a baseline correction issue somewhere since the only difference between how I processed this set of data compared to how I traditionally do was the removal of the baseline from everything.
When I produced some stc files using bmin of -200 and bmax of 0, they did match (up to the tenths place at least). So perhaps this is the issue here, but really this just reverts me back to the same issue I had at the beginning of this thread. I'll try averaging from the beginning with a baseline of -200 rather than -500 ms and see if that improves the mismatch in the SNR estimate display.