Back to the main page.

Bug 380 - implement ztransform/standardize in rejectvisual

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
Depends on:
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?

Robert Oostenveld - 2011-03-18 13:33:30 +0100

(In reply to comment #4) the second, i.e. > that channels will not appear 'bad' with this metric, and so people will not select them as bad?