Back to the main page.

Bug 3227 - ft_datatype_source chokes on 'rawtrial' source level data with filters kept

Status NEW
Reported 2017-01-02 21:48:00 +0100
Modified 2017-01-06 12:17:19 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to:
Depends on:
See also:

Jan-Mathijs Schoffelen - 2017-01-02 21:48:19 +0100

This came up on the discussion list. If I recall well, Jens in CC has reported this in the past. Sounds like a good time to fix it (rather than telling users not to specify cfg.rawtrial in combination with cfg.METHOD.keepfilter='yes';

Jens Klinzing - 2017-01-04 12:57:05 +0100

(In reply to Jan-Mathijs Schoffelen from comment #0) Yes, that was bug #2861

Jens Klinzing - 2017-01-05 15:32:00 +0100

So, currently if you call ft_sourceanalysis with cfg.rawtrial = 'yes' and cfg.keepfilter = 'yes' calling ft_datatype_source on the result will fail. The reason is the additional field source.trial.label (actually not .trial.filter) because it is expected to have as many rows as there are source points but it obviously only has as many rows as there are channels... (ft_datatype_source, line 187). This problem occurs whether you provide a filter when calling ft_sourceanalysis or not. Suggestions how to solve the problem: 1) Stop allowing the user to set cfg.rawtrial while providing a filter. Either you want to construct the filter from each single trial (is there a situation where this makes sense?) or you provide your own filter. Why would you want both at the same time? 2) Change the code in a way that it parallels the PCC code (ie. you call ft_sourceanalysis only once, with keeptrials = yes, which computes a common filter and applies it to the single trials)? If that is not feasible, why not call ft_sourceanalysis twice, once with keepfilter = yes and the second time with keeptrials = yes while providing the filter (why should there be rawtrials involved?). If the user sets keepfilter = 'yes' for the second call, just attach the provided filter to the output.

Jan-Mathijs Schoffelen - 2017-01-06 09:58:16 +0100

(In reply to Jens Klinzing from comment #2) I agree with you that we should clean up the rather opaque (and historically 'grown') options in ft_sourceanalysis rawtrial/singletrial/keeptrials. Yet, I am a bit reluctant to patch this, because building patch upon patch upon patch is ugly and not efficient, and I'd rather do a big overhaul in a single step in this case. However, this requires much more thought. As an alternative, we could -disable the combination 'rawtrial'/'keepfilter', i.e. throw an error -exclude the label field to be treated the same as the other cell-array type datafields in ft_datatype_source -put the spatial filter one level up in the output structure: if I recall well, in the past (with rawtrial + filters present) the filter ended up both at source.trial(x).filter, and at source.filter, causing problems as well... What a mess :o)

Jens Klinzing - 2017-01-06 12:17:19 +0100

I understand your points. So let's just keep it running for now, while keeping the user from making mistakes. Currently, setting the rawtrial option constructs the spatial filter on single trials if no filter is provided. However, it effectively turns into a keeptrials option in case a filter is provided - but not for PCC where there is no rawtrial option. If it should stay this way, I think we should explain this somewhere in the documentation. You suggested to disable the 'rawtrial'/'keepfilter' combination. However, if we allow the user to construct spatial filters based on single trials, maybe he/she should be able to keep those filters as well. Or are single-trial filters deprecated anyways, so it doesnt have to be supported? To your second point, in my last try I only got back the single trial-based filters at source.trial(x).filter in the output, without a source.filter.