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: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| 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)