Closed srcole closed 6 years ago
Another example: standard CA1 LFP with hippocampal theta, which looks like a classic PSD with a flat slope and some bumps. However, the background fit is too low, so there are extra bumps fitted.
@rdgao said he would implement an exponential fit that might work better.
We have a few options.
0) Find a better generalized background fit than the current quadratic. 1) Fit several different 1/f backgrounds (power, exp, linear, quadratic) and choose the one with smallest RMSE right from the get go. 2) Flexibly update fitting models based on input frequency range (maybe for 2-30 Hz, quadratic is best, but for 2-100 exponential is best?)
Then return the fitting model type and equation. Also return the 1/f slope as estimated from a linear fit of the returned background in log-log space (regardless of the resultant best fit equation) across the 30-50 Hz range (per Gao's paper) to get a 1/f slash EI estimate.
@srcole can you attach the data for this one? I haven't been testing on such broad ranges (or any LFP) - it may be that our presets or algorithm are inappropriate.
I think, overall, we have to figure out clearly what FOOOF is supposed to be doing, and from there, what is a bug, what is simply outside the scope of (current) FOOOF. There has to be decision points on what we solve, when. Currently, FOOOF assumes, and will only work, given data with a single background slope.
@srcole: the LFP data (plotted in log-log) seems to violate this assumption, and so FOOOF fails. It does seem to work well applied on smaller ranges.
Although not by design, practically, it appears the scope of current FOOOF simply doesn't cover broad freq ranges (such as 1-100), as a consequence of them basically always violating the single slope assumption. Given this multiple slope issue, it seems likely, current FOOOF will simply never, in a single fit, be appropriate for a wide range, such as 1-100 Hz, potentially limiting some of it's use with ECoG & LFP (although it can be applied piece-wise). This is a pretty annoying limitation, and limits current FOOOF more than we might have wanted. Whatever we do, as in the original point of this issue, we need to be super clear about this limitation for current FOOOF (in so far as we keep this version)
With this all in mind, @voytek suggestions: 0) Yes, if we want to generalize to broader frequency ranges - effectively broadening the scope of FOOOF. 1) I vote no. Maybe the user could preset which fit to use, given their data, but allowing the algorithm to choose heuristically would make meaningful comparisons across PSDs / between fits impossible. 2) Maybe. This is also broadening the scope of FOOOF, given what's noted above that broad range seems likely to never meet the assumptions.
Ultimately, there are many expansions and possible updates to FOOOF. Our current question is: what is v0.1 for, and given that, what should it do? I understand v0.1 to be dealing with the single slope case - that may or may not be good enough. Deciding if it is or not, is the first required decision point.
A note on exponential fits: Given that the issue here seems to be slope changes, wouldn't fitting a single exponential have all the same pitfalls? It's not clear to me that offers a fix, but it's potentially worth trying. However, if the real problem is changes in slope, then we would then need to figure out how to algorithmically find knees.
For the LFP data, attached are log-log, full spectrum (terrible fit, can see the slope violates the assumption though). Picking ranges which are approximately single-sloped works.
Param note: min_amp set to 0.2.
Clearly state you assume one 1/f background noise process. Then clearly explain meeting this assumption often means working with a subset of the spectrum. Then....
Publish!
No more scope creep, please....
(e)
On Aug 31, 2017, at 1:03 PM, Tom notifications@github.com wrote:
For the LFP data, attached are log-log, full spectrum (terrible fit, can see the slope violates the assumption though). Picking ranges which are approximately single-sloped works.
Param note: min_amp set to 0.2.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
But scope creep is where the fun is, Erik! Publishing is awful. (But yes, I agree. I believe we all agree on this point, now.)
@parenthetical-e : I very much agree, and yes, I think we're all on the same page now.
@voytek @srcole @rdgao : Let's consider v0.1 locked in as far as algorithmic changes go (unless anyone wants to try and argue otherwise), and stick to that, short of any newly discovered major issues. I'm going to wrap up the last small things, and add better notes to docs & tutorials and assumptions and limitations, then tag a release.
Once v0.1 is locked in and put out, we can all start fresh on the exciting new world of v0.2 - for better or worse, we haven't entirely finished characterizing PSDs - and we can continue onwards from there.
HAHAHAHAHAH at August 31st "okay we're ready to lock in v0.1".....
This issue / discussion has been addressed by adding knee fitting options. Closing.
I'm fitting a PSD of motor cortical ECoG data (same data as issue #20), and it may be a bit unique because it does not have a consistent slope across the frequency range I'm interested in fitting.
If I fit 1-100Hz, then I end up with a lot of "peaks" to fill in the power above the beta range, since the curve fit is at a much lower power. If I fit 1-40Hz, the peak seems reasonable, but I would have to know to do this, but the slope is pretty meaningless.
It would be really great if fooof was able to recognize if the slope fit is really bad and notify the user that the fit is not good. But I acknowledge that's a really tough problem. I'll try to think of possible ways to handle this.