Back to the main page.
Bug 208 - ft_ prefix inverse module
| Status | CLOSED FIXED |
| Reported | 2010-11-10 10:15:00 +0100 |
| Modified | 2021-10-29 12:38:35 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 enhancement |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jan-Mathijs Schoffelen - 2010-11-10 10:15:35 +0100
the functions in the inverse module need an ft_ prefix
Robert Oostenveld - 2011-03-23 12:43:22 +0100
furthermore, they have to be (internally) reorganized to create an API that is consistent with the other modules, i.e. the FT specified data structures should be avoided. E.g. the scanning/distributed methods should take a leadfield matrix as input and loop over that, instead of using the grid structure, doing the inside/outside detection, compute the leadfields, and only then get to work. The shared code for the source-space handling should move to the (higher-level) ft_sourceanalysis function. It is quite a large change and therefore I think that it is good to make a compat directory which will contain the functions with the old interface, which then call the new ft_inverse functions. That means that sourceanalysis would not immediately have to be changed along
Johanna - 2013-04-17 14:40:45 +0200
explicit request related to bug 2094 is to include sLORETA (e.g. from Nutmeg) after this bug is implemented. (as well, more generally, other inverse functions in Nutmeg).
Robert Oostenveld - 2020-06-30 17:38:04 +0200
Looking at this, I see that I already made a design for this once, which is actually part of the FieldTrip release mac036-lan> ls -al fieldtrip/inverse/new/ total 80 -rw-r--r-- 1 roboos staff 13362 Jun 28 2018 ft_inverse_beamformer_dics.m -rw-r--r-- 1 roboos staff 162 Jun 28 2018 ft_inverse_beamformer_lcmv.m -rw-r--r-- 1 roboos staff 154 Jun 28 2018 ft_inverse_beamformer_pcc.m -rw-r--r-- 1 roboos staff 161 Jul 4 2017 ft_inverse_dipolefit.m -rw-r--r-- 1 roboos staff 153 Jul 4 2017 ft_inverse_mne.m -rw-r--r-- 1 roboos staff 149 Jul 4 2017 ft_inverse_music.m -rw-r--r-- 1 roboos staff 182 Jul 4 2017 ft_inverse_residualvariance.m The idea back then (exemplified for dics) was to replace the dip structure input by a single cell-array of leadfields. This would mean that ft_compute_leadfield would not be called by these functions any more. However, this is a large change. I propose for now simply to rename the functions and to keep their API the same, i.e. they get a sourcemodel with pos and optionally a leadfield as input.
Robert Oostenveld - 2020-06-30 17:49:42 +0200
I have renamed them like this, which makes the names consistent with the cfg.method=xxx in ft_sourceanalysis. renamed: beamformer_dics.m -> ft_inverse_dics.m renamed: dipole_fit.m -> ft_inverse_dipolefit.m renamed: ft_eloreta.m -> ft_inverse_eloreta.m renamed: harmony.m -> ft_inverse_harmony.m renamed: beamformer_lcmv.m -> ft_inverse_lcmv.m renamed: minimumnormestimate.m -> ft_inverse_mne.m renamed: music.m -> ft_inverse_music.m renamed: beamformer_pcc.m -> ft_inverse_pcc.m renamed: residualvariance.m -> ft_inverse_rv.m renamed: beamformer_sam.m -> ft_inverse_sam.m renamed: ft_sloreta.m -> ft_inverse_sloreta.m I now have to go through all other code to replace the function calls accordingly
Robert Oostenveld - 2020-06-30 18:31:45 +0200
this has been addressed with https://github.com/fieldtrip/fieldtrip/pull/1472
Jan-Mathijs Schoffelen - 2020-06-30 20:04:03 +0200
Wist je nog hoe je hier die status moest veranderen? :)
Jan-Mathijs Schoffelen - 2020-06-30 20:29:32 +0200
I agree with keeping the API as is for now. Note: should we also seize the opportunity to make the whole prewhitening business consistent across the codebase ft_dipolefitting/ft_denoise_prewhiten/ft_inverse_mne?