Back to the main page.
Bug 380 - implement ztransform/standardize in rejectvisual
| Status | CLOSED FIXED |
| Reported | 2011-01-11 09:06:00 +0100 |
| Modified | 2011-03-30 13:46:32 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 enhancement |
| Assigned to: | Johanna |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-01-11 09:06:38 +0100
there is a standardize option in private/preproc, but that computes the mean and std for each trial, whereas the mean and std should be computed over all trials. cfg.ztransform = yes/no should cause for each channel compute mean and std subtract mean and divide by std end
Jan-Mathijs Schoffelen - 2011-01-11 09:12:21 +0100
And this is where JM's cellfunction toolbox comes in handy. See e.g. ft_denoise_pca. Here the different functions are copied into the main function, as subfunctions
Johanna - 2011-01-26 17:14:59 +0100
Notes to self: Create option cfg.metric='zvalue' Anything of use from ft_artifact_zvalue to bring in here? Questions: Valid only for cfg.method='summary' ? The zvalue that will be computed for each channel and over trials: is it specific to each timepoint in trial (including variable-length trials), or also mean/std over timepoints within trial?
Robert Oostenveld - 2011-01-26 20:15:39 +0100
the summary stats have to be compressed in a Nchan X Ntrials matrix "M". For a given channel it should allow identifying the bad trials. The mean could be estimated per trial (or more convenient: demean the data in each trial), but the std not. I would rather think that the sum of squares is accumulated over all samples in all trials (after demeaning) and used for the std estimate. Subsequently per channel and timepoint the data can be z-transformed. After that, the mean z-value over all timepoints per trial (and channel) is computed and stored in matrix "M". Prior to the case metric='zscore' the data is passed through the private/preproc function, which is where the interesting stuff should be done: e.g. bandpassfilter and hilbert. Note that this metric would _not_ allow identifying bad channels.
Johanna - 2011-03-18 13:24:25 +0100
I've implemented this. However, Robert, when you say the z-value would not allow identifying bad channels, I agree with you theoretically, but do you want some additional check in place in the code to _prevent_ people from marking bad channels in the interactive selection? Or do you simply mean that channels will not appear 'bad' with this metric, and so people will not select them as bad?