Back to the main page.
Bug 2235 - ft_denoise_synthetic changes grad labels
| Status | CLOSED FIXED |
| Reported | 2013-08-08 13:52:00 +0200 |
| Modified | 2014-01-15 14:45:48 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Alexander Backus - 2013-08-08 13:52:49 +0200
Created attachment 502 Artifact rejected MEG data, before denoising Szabolcs Szebenyi, an MSc student working in our group, has encountered the following problem we would like to report: ft_denoise_synthetic seems to change the order (just the order, not the value) of the 28 reference coils in grad.label, grad.chanpos, grad.chanori. However, the function does not change the order in grad.chantype. We suspect that for some of the later FieldTrip steps (probably ICA, or rejectvisual or resample), this leads to confusion and the function just replaces all corrupted chanpos and chanori fields with NaNs (this actually was the original problem that led to our investigation), and, interestingly, it also corrects the grad.chantype field according to the original labels. The code of interest looks as follows: ________________________________________________ load('a_data.mat'); % artifact rejected MEG data % denoise meg using the 3rd order gradient cfg = []; cfg.gradient = 'G3BR'; cfg.trials = 'all'; da_data = ft_denoise_synthetic(cfg, a_data); % to quickly see that some chanpositions and orientations changed a_data.grad.chanpos == da_data.grad.chanpos a_data.grad.chanori == da_data.grad.chanori a_data.grad.coilpos == da_data.grad.coilpos a_data.grad.coilori == da_data.grad.coilori a_data.grad.chantype da_data.grad.chantype a_data.grad.label da_data.grad.label ________________________________________________ Best, Szabolcs Szebenyi & Alexander Backus
Jan-Mathijs Schoffelen - 2013-08-09 09:08:45 +0200
Thanks for the detailed report, Alex. We'll look into it. I think that the NaN issue is unrelated and has to do with the fact that backprojected component data (essentially doing a sequence of ft_componentanalysis and ft_rejectcomponent) replaces the chanpos/ori with NaN. The changing order should however be investigated. Could you ask Szabi to also make a bugzilla account? Then he can be added to the CC list.
Alexander Backus - 2013-08-09 10:31:27 +0200
(In reply to comment #1) Thanks JM, for the fast reply! The full story behind this investigation is that we had to replace the post-ICA grad with a pre-ICA grad in order to be able to perform beamforming ect. Problem was we only saved a pre-denoise version of the grad field to disk, so we wanted to make sure that the denoising didn't change the grad field before we used it for beamforming. Turned out the grad field was changed - or at least the order of the labels. At this point, we didn't know which grad to use. Anyway, replacing the post-ICA grad field with an older version seems like a weird procedure to us, so two questions: 1) Why does the ICA kill the grad field if it is safe (is it?) to replace with an older version for beamforming? Is it necessary? 2) If this is the case and standard, couldnt the old grad be kept in the post-ICA data structure, so that it can be automatically found by source model functions? May be slightly off topic for this bug - my apologies. Best, Alex
Jan-Mathijs Schoffelen - 2013-11-29 11:35:53 +0100
copied data over, and created test function