Back to the main page.

Bug 1142 - the cfg history is not fully kept in e.g. the artifact handling

Status ASSIGNED
Reported 2011-11-11 11:11:00 +0100
Modified 2011-12-07 22:11:25 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: All
Importance: P3 enhancement
Assigned to: Robert Oostenveld
URL:
Tags:
Depends on: 951
Blocks:
See also:

Robert Oostenveld - 2011-11-11 11:11:02 +0100

Following yesterdays BBM of David, Stan and I gave it a try to see whether the analysis protocol is fully documented in data.cfg.previous.previous... It turned out that it was cut of at ft_rejectartifact, i.e. the details of the preceding ft_preprocessing were not stored. This issue is one that I recently also came across when building in the "ft_postable history". The role of the ft_artifact_xxx functions and of the ft_rejectartifact function has changed over time: in the old days they were called prior to preprocessing, but now they are often used after preprocessing. These functions still allow either to work on only a cfg, or on a cfg and data. Looking at manzana> grep -L 'ft_postamble history' *.m there are quite some functions that don't seem to keep the history. There is also bug 951 about the plotting functions having inconsistent return values. Ideally a matlab figure could be traced back to the full analysis details. Another area where I know that the cfg history is lost is in the construction of the volume conduction models and leadfields. E.g. ft_prepare_leadfield produces a grid, which is added to cfg for sourceanalysis. But after sourceanalysis you cannot check what the cfg parameters were of ft_prepare_leadfield or of the headmodel that went into it.


Robert Oostenveld - 2011-11-14 09:00:22 +0100

I created an initial test script that goes over all possible options for the artifact pipeline. See fieldtrip/test/test_bug1142.m


Boris Reuderink - 2011-11-17 10:46:42 +0100

Changed the status of bugs without a specific owner to UNCONFIRMED. I'll try to replicate these bugs (potentially involving the submitter), and change confirmed bugs to NEW. Boris


Boris Reuderink - 2011-11-23 14:12:04 +0100

Added this bug to Eelke as well, since it is related to bug 1142.


Robert Oostenveld - 2011-11-26 02:32:14 +0100

we should discuss in the FT meeting how to deal with the genetic handling of the cfg in the following types of functions - ft_definetrial - ft_artifact_xxx - etc which are called in succession and which modify the cfg - ft_prepare_layout - ft_prepare_sourcemodel - ft_prepare_headmodel which create a "helper structure" that is added to another cfg There are perhaps other general cases that are currently not properly dealt with.


Robert Oostenveld - 2011-12-07 12:11:36 +0100

at this moment the ft_prepare functions behave like this function [atlas] = ft_prepare_atlas(filename) function [bnd] = ft_prepare_mesh(cfg, mri) function [bnd] = ft_prepare_mesh_new(cfg, data) function [grid, cfg] = ft_prepare_leadfield(cfg, data) function [grid, cfg] = ft_prepare_sourcemodel(cfg, vol, sens) function [lay] = ft_prepare_layout(cfg, data) function [neighbours] = ft_prepare_neighbours(cfg, data) function [vol, cfg] = ft_prepare_bemmodel(cfg, mri) function [vol, cfg] = ft_prepare_concentricspheres(cfg) function [vol, cfg] = ft_prepare_localspheres(cfg, mri) function [vol, cfg] = ft_prepare_singleshell(cfg, mri) function [vol] = ft_prepare_headmodel(cfg, data) so some of them return a cfg as second output argument. For most functions this is undocumented behaviour, but ft_prepare_sourcemodel and the ft_prepare functions for the old headmodels documents it. The internal use of the output cfg can be found as follows manzana> grep cfg].*=.*ft_prepare *.m ft_dipolefitting.m: [grid, tmpcfg] = ft_prepare_sourcemodel(tmpcfg); ft_headmodelplot.m: [sourcegrid, tmpcfg] = ft_prepare_sourcemodel(tmpcfg); ft_megrealign.m:[grid, tmpcfg] = ft_prepare_sourcemodel(tmpcfg); ft_prepare_bemmodel.m:function [vol, cfg] = ft_prepare_bemmodel(cfg, mri) ft_prepare_bemmodel.m:% [vol, cfg] = ft_prepare_bemmodel(cfg, mri), or ft_prepare_bemmodel.m:% [vol, cfg] = ft_prepare_bemmodel(cfg, seg), or ft_prepare_bemmodel.m:% [vol, cfg] = ft_prepare_bemmodel(cfg, vol), or ft_prepare_bemmodel.m:% [vol, cfg] = ft_prepare_bemmodel(cfg) ft_prepare_concentricspheres.m:function [vol, cfg] = ft_prepare_concentricspheres(cfg) ft_prepare_concentricspheres.m:% [vol, cfg] = ft_prepare_concentricspheres(cfg) ft_prepare_leadfield.m:function [grid, cfg] = ft_prepare_leadfield(cfg, data) ft_prepare_leadfield.m:[grid, tmpcfg] = ft_prepare_sourcemodel(tmpcfg); ft_prepare_localspheres.m:function [vol, cfg] = ft_prepare_localspheres(cfg, mri) ft_prepare_localspheres.m:% [vol, cfg] = ft_prepare_localspheres(cfg, seg), or ft_prepare_localspheres.m:% [vol, cfg] = ft_prepare_localspheres(cfg, mri), or ft_prepare_localspheres.m:% [vol, cfg] = ft_prepare_localspheres(cfg) ft_prepare_singleshell.m:function [vol, cfg] = ft_prepare_singleshell(cfg, mri) ft_prepare_singleshell.m:% [vol, cfg] = ft_prepare_singleshell(cfg, seg), or ft_prepare_singleshell.m:% [vol, cfg] = ft_prepare_singleshell(cfg, mri), or ft_prepare_singleshell.m:% [vol, cfg] = ft_prepare_singleshell(cfg) ft_prepare_sourcemodel.m:function [grid, cfg] = ft_prepare_sourcemodel(cfg, vol, sens) ft_sourceanalysis.m: [grid, cfg] = ft_prepare_leadfield(cfg, data); ft_sourceanalysis.m: [grid, cfg] = ft_prepare_leadfield(cfg, data); ft_sourceanalysis.m: [grid, tmpcfg] = ft_prepare_sourcemodel(tmpcfg); None of them seems too severe to change to a single output argument, so I will change the following manzana> grep -l cfg].*=.*ft_prepare *.m ft_dipolefitting.m ft_headmodelplot.m ft_megrealign.m ft_prepare_bemmodel.m ft_prepare_concentricspheres.m ft_prepare_leadfield.m ft_prepare_localspheres.m ft_prepare_singleshell.m ft_prepare_sourcemodel.m ft_sourceanalysis.m


Robert Oostenveld - 2011-12-07 12:14:23 +0100

for consistency and backward compatibility of end-users code, I have changed the ft_prepare* functions API into function [atlas, cfg] = ft_prepare_atlas(filename) function [vol, cfg] = ft_prepare_bemmodel(cfg, mri) function [vol, cfg] = ft_prepare_concentricspheres(cfg) function [vol, cfg] = ft_prepare_headmodel(cfg, data) function [lay, cfg] = ft_prepare_layout(cfg, data) function [grid, cfg] = ft_prepare_leadfield(cfg, data) function [vol, cfg] = ft_prepare_localspheres(cfg, mri) function [bnd, cfg] = ft_prepare_mesh(cfg, mri) function [bnd, cfg] = ft_prepare_mesh_new(cfg, data) function [neighbours, cfg] = ft_prepare_neighbours(cfg, data) function [vol, cfg] = ft_prepare_singleshell(cfg, mri) function [grid, cfg] = ft_prepare_sourcemodel(cfg, vol, sens) I have changed the documentation not to mention the second (cfg) output argument. I have changed the other FT functions not to ask for the second output argument.


Robert Oostenveld - 2011-12-07 22:11:25 +0100

I have made the changes to th eft_prepare_xxx functions. Except for the ft_prepare_mesh (and new) function, all now return in their output the cfg, including the previous history. What remains to be done is ft_definetrial and ft_artifact_xxx. manzana> svn commit Sending ft_dipolefitting.m Sending ft_headmodelplot.m Sending ft_megrealign.m Sending ft_prepare_bemmodel.m Sending ft_prepare_concentricspheres.m Sending ft_prepare_headmodel.m Sending ft_prepare_layout.m Sending ft_prepare_leadfield.m Sending ft_prepare_localspheres.m Sending ft_prepare_mesh.m Sending ft_prepare_mesh_new.m Sending ft_prepare_neighbours.m Sending ft_prepare_singleshell.m Sending ft_prepare_sourcemodel.m Sending ft_sourceanalysis.m Transmitting file data ............... Committed revision 4955.