Different results with repeated runs of clean_rawdata
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
Research direction
Start by locating clean_artifacts, pop_clean_rawdata, and the clean_channels path, then reproduce repeated runs with a dataset shorter than 150,000 samples and the described low-pass setting. Confirm how EEG.data length is measured and where a warning can be emitted for both function and GUI use. Done means short-data processing clearly warns users and repeated-run behavior is covered by a regression check.
Written by the indexing model from the issue text.
Description
Hi there,
I just followed up on this thread (https://sccn.ucsd.edu/pipermail/eeglablist/2020/015456.html) I found on the eeglablist about inconsistent results when using clean_artifatcs for bad channel detection and removal. I encounter the same problem. After running quite a few tests with a couple of different datasets and different parameters I think I observed the following. Results are inconsistent when:
- The recording is short (less than 10 minutes recorded at 1000Hz before downsampling at 250Hz). So, in general, when the data has less than 150.000 samples. The less the number of samples, the more inconsistent the results are.
- The cut-off for the low-pass filter is 0.1 (as used in ERP research - I did not test with lower than this).
In my testing, these two conditions needed to be met in order to find inconsistent results. Furthermore, they were related, as the lower the number of samples, the higher the cut-off necessary to create inconsistent results. I think the problem arises from the use of rand() in clean_channels called in the background. Setting a seed create stable results, but it is difficult to tell which channels are actually bad.
I do understand this is a problem that not many people might run into given these conditions but it could be helpful to have a warning appearing (or simply being displayed on the console) in case someone is trying to process a short dataset
Proposed solution
Add a warning when calling clean_artifacts or pop_clean_rawdata (as it uses the former) if the length of EEG.data is shorter than N (I would say 150.000, that is 10minutes sampled/downsampled at 250Hz). A simple implementation would be:
if length(EEG.data) < 150000
warning('clean_artifacts: The dataset is rather short. It is possible to encounter inconsistent results for the detection of bad channels. Try a few times to verify this. ')
end
This for both the function (maybe in pop_clean_rawdata) the message could be displayed in a window (as it is likely that people are using the GUI in that case).
Thank you,
Daniele
- Dominant language
- MATLAB
- Stars
- 55
- Forks
- 19
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sccn/clean_rawdata
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
sccn/clean_rawdata#45 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 20/100
sccn/clean_rawdata#43 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
sccn/clean_rawdata#38 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
sccn/clean_rawdata#33 · 3 comments ·
-
wontfix
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sccn/clean_rawdata#4 · 1 comment ·
All issues in sccn/clean_rawdata
Similar issues
-
C++ Enhancement Examples
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Component: Continuous Integration Component: MATLAB Type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
VH-Lab/NDIcalc-vis-matlab#107 ·
-
bug unconfirmed
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
gnu-octave/statistics#498 ·