-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
BUG: Fix bug with optical_density #9522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -42,25 +42,28 @@ def scalp_coupling_index(raw, l_freq=0.7, h_freq=1.5, | |
| ---------- | ||
| .. footbibliography:: | ||
| """ | ||
| raw = raw.copy().load_data() | ||
| _validate_type(raw, BaseRaw, 'raw') | ||
|
|
||
| if not len(pick_types(raw.info, fnirs='fnirs_od')): | ||
| raise RuntimeError('Scalp coupling index ' | ||
| 'should be run on optical density data.') | ||
| if 'fnirs_od' not in raw: | ||
| raise RuntimeError( | ||
| 'Scalp coupling index should be run on optical density data.') | ||
|
|
||
| freqs = np.unique(_channel_frequencies(raw.info, nominal=True)) | ||
| picks = _check_channels_ordered(raw.info, freqs) | ||
|
|
||
| filtered_data = filter_data(raw._data, raw.info['sfreq'], l_freq, h_freq, | ||
| picks=picks, verbose=verbose, | ||
| l_trans_bandwidth=l_trans_bandwidth, | ||
| h_trans_bandwidth=h_trans_bandwidth) | ||
| raw = raw.copy().pick(picks).load_data() | ||
| zero_mask = np.std(raw._data, axis=-1) == 0 | ||
| filtered_data = raw.filter( | ||
| l_freq, h_freq, l_trans_bandwidth=l_trans_bandwidth, | ||
| h_trans_bandwidth=h_trans_bandwidth).get_data() | ||
|
|
||
| sci = np.zeros(picks.shape) | ||
| for ii in picks[::2]: | ||
| c = np.corrcoef(filtered_data[ii], filtered_data[ii + 1])[0][1] | ||
| for ii in range(0, len(picks), 2): | ||
| with np.errstate(invalid='ignore'): | ||
| c = np.corrcoef(filtered_data[ii], filtered_data[ii + 1])[0][1] | ||
| if not np.isfinite(c): # someone had std=0 | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this mean that the channel is flat? I.e. it's all the same value? If this is the case would it not be better to throw the user a warning and tell them to set it to bad?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Warning could be useful, yeah. This was mostly just laziness since I think/hope the outcome of the algorithm is still to clearly say the channel is bad anyway (e.g., with a SCI of 0). Maybe I should assert this in a test, then a warning isn't necessary? Or maybe we need both warning and sci=0?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right, as long as it comes out with a 0 value the result will be the same to the user. We should probably have a flat signal check as a seperate function check. I think I have seen that around somewhere in MNE already, Ill look.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes we have a flat marking / annotating function https://mne.tools/stable/generated/mne.preprocessing.annotate_flat.html |
||
| c = 0 | ||
| sci[ii] = c | ||
| sci[ii + 1] = c | ||
|
|
||
| sci[zero_mask] = 0 | ||
| return sci | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -132,6 +132,8 @@ def _TDDR(signal, sample_rate): | |
| sigma = 1.4826 * np.median(dev) | ||
|
|
||
| # Step 3d. Scale deviations by standard deviation and tuning parameter | ||
| if sigma == 0: | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this also indicate a flat channel? As above.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do try and keep the code as close to the original as possible could we add the flat signal check as a block at the front?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could but I don't mind the small diff that's a clear fix here. It ends up being less clean to do it at the beginning I think because it creates redundant calculations |
||
| break | ||
| r = dev / (sigma * tune) | ||
|
|
||
| # Step 3e. Calculate new weights according to Tukey's biweight function | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you set it to _min and not something like eps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
epsis relative to1.and is around 1e-12. Imagine you had data in the femto/1e-15 or smaller range, yournp.finfo(float).epswould actually be a "large" value relative to this scale.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @larsoner, turns out I didnt understand eps properly. I wonder how many bugs I have introduced over the years!