Back to the main page.
Bug 1708 - ft_denoise_synthetic sets all grad.chanpos and grad.chanori to NaN
| Status | CLOSED WONTFIX |
| Reported | 2012-09-12 14:36:00 +0200 |
| Modified | 2015-07-20 10:19:30 +0200 |
| Product: | FieldTrip |
| Component: | preproc |
| Version: | unspecified |
| Hardware: | All |
| Operating System: | All |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Andreas Wollbrink - 2012-09-12 14:36:11 +0200
using the function ft_denoise_synthetic the values for grad.chanori and grad.chanpos are set to NaN which disables the usage of the corresponding data structure to be used for later processings steps (for example ft_prepare_leadfield) example code: % split data in event related trials cfg = []; cfg.dataset = dsName; cfg.channel = chanUsed; cfg.trl = trlOrg; trialData = ft_preprocessing(cfg); % define noise balancing (synthetic gradiometer order) cfg = []; cfg.gradient = 'G3BR'; trialDataBal3 = ft_denoise_synthetic(cfg, trialData);
Roemer van der Meij - 2012-09-14 10:58:11 +0200
*** Bug 1710 has been marked as a duplicate of this bug. ***
Jan-Mathijs Schoffelen - 2012-09-14 11:12:34 +0200
bash-3.2$ svn add test_bug1708.m A test_bug1708.m bash-3.2$ svn commit test_bug1708.m Adding test_bug1708.m Transmitting file data . Committed revision 6457. Hi Andreas, I cannot reproduce the error on some test data of our own (using the above script). Could you upload a small data structure (i.e. at least containing a .grad and some other necessary stuff), in order that we can look what is going on. At this moment I have reasons to believe that there is something going on in your data.
Roemer van der Meij - 2012-09-14 12:27:00 +0200
*** Bug 1713 has been marked as a duplicate of this bug. ***
Jan-Mathijs Schoffelen - 2012-09-14 13:19:25 +0200
Hi Andreas, In your data there seems to be a mismatch between the channels that are specified in the balancing structures: avgData.grad.balance.GxBR: for the first and second order gradient, there are 281 channels, for the G3BR there are 288. This is what confuses FieldTrip, and to be on the safe side, it removes the channel position and channel orientation info. Note that this does not affect the coil position and coil orientation info. As such forward computations should still be possible. Do you agree that this is a feature in your data and not a bug in FieldTrip?
Jan-Mathijs Schoffelen - 2012-09-14 13:23:23 +0200
Additional comment: I just noticed that something similar is the case in our data ;-), i.e. the number of channels in the G3BR balancing structure is > the number of channels for G(1/2)BR. The difference though with our data is, that at the level of the grad structure the number of channels (as defined in grad.label) equals grad.balance.G3BR.labelorg/labelnew, whereas in your data the grad.label equals grad.balance.G1BR.labelorg/labelnew
Jan-Mathijs Schoffelen - 2012-09-14 13:35:18 +0200
Did you record the data in G1BR?
Andreas Wollbrink - 2012-09-14 14:18:42 +0200
(In reply to comment #6) yes, the recording / acquisition was done using balancing level 1
Jan-Mathijs Schoffelen - 2012-09-14 14:57:35 +0200
OK. Then it seems that the cause of the problem should be sought higher up: fieldtrip/fileio/private/ctf2grad.m applies the balancing on line 212. I suspect that the information from the additional coils is lost here, causing the 'problem' later on. I think we need to address the issue, but for now I am wondering what is exactly causing the problems for you downstream in your analysis. As I mentioned before, it shouldn't be the case that forward modeling fails, because the coil position and orientation is what counts there, and those are still represented correctly (I think) in the grad-structure. At least they are not nan.
Andreas Wollbrink - 2012-09-14 15:28:34 +0200
(In reply to comment #8) the problem encounters when one tries to prepare a leadfield matrix using the following code: %%%% first line of code % load volumeconductor model volCondModelName = 'singleShell.mat'; load(volCondModelName, 'vol'); %% option1 : get grad from preprocessed data (including ft_denoise_synthetic) load('SyntheticGrad.mat', 'avgDataBal3'); % calculate leadfield matrix used as search grid during beamforming gridRes = 10; % search grid resolution [mm] cfg = []; cfg.grad = avgDataBal3.grad; cfg.vol = vol; cfg.reducerank = 2; cfg.channel = {'MEG' 'MEGREF'}; cfg.grid.resolution = gridRes/10.0; % use a 3-D grid leadfield = ft_prepare_leadfield(cfg); %% option2 : get grad from raw data load('hdr.mat', 'hdr'); % calculate leadfield matrix used as search grid during beamforming gridRes = 10; % search grid resolution [mm] cfg = []; cfg.grad = hdr.grad; cfg.vol = vol; cfg.reducerank = 2; cfg.channel = {'MEG' 'MEGREF'}; cfg.grid.resolution = gridRes/10.0; % use a 3-D grid leadfield2 = ft_prepare_leadfield(cfg); %%% last line of code option 1 fails, option 2 works out I just tried to add an additional attachment including an archive with all the files I used running the script. I might have failed since I did not get any further response from the bugzilla server. Please let me know in case you need the archive for further problem solving
Jan-Mathijs Schoffelen - 2012-09-14 15:31:27 +0200
What's the error message?
Andreas Wollbrink - 2012-09-14 15:33:22 +0200
(In reply to comment #10) the error / report message is the following: using headmodel specified in the configuration using gradiometers specified in the configuration computing surface normals creating dipole grid based on automatic 3D grid with specified resolution using headmodel specified in the configuration using gradiometers specified in the configuration 0 dipoles inside, 0 dipoles outside brain making tight grid 0 dipoles inside, 0 dipoles outside brain the call to "ft_prepare_sourcemodel" took 0 seconds and required the additional allocation of an estimated 0 MB computing leadfield the call to "ft_prepare_leadfield" took 3 seconds and required the additional allocation of an estimated 3 MB
Jan-Mathijs Schoffelen - 2012-09-14 15:54:36 +0200
OK, so the problem seems to be that the ft_prepare_sourcemodel fails to construct a meaningful 3D-grid given the input.
Jan-Mathijs Schoffelen - 2012-09-16 09:00:14 +0200
So, we have identified 2 problems: -ctf2grad should keep the unused channels when converting to a different balancing scheme. Apparently, only all channels/coils are kept in the case of 'none' and 'G3BR'. -ft_prepare_sourcemodel with a cfg that contains both a vol and a grad, and furthermore asks for a 3D grid with only the resolution parameter specified, yields a 0-dipole grid, when the chanpos in the grad contains only nans.
Jan-Mathijs Schoffelen - 2012-09-19 15:27:22 +0200
Hi Andreas, Would it be possible to upload a .res4 file that was recorded with first-order balancing switched on? Thanks, JM
Andreas Wollbrink - 2012-09-19 16:33:59 +0200
(In reply to comment #14) Hi Jan-Mathijs, yes sure. How should we perform the data transfer? I can either put a dataset on our ftp server (and provide you with the access information) or are there options to upload such a large file directly to your environment. Please let me know how to proceed. Andreas
Jan-Mathijs Schoffelen - 2012-09-19 16:53:00 +0200
Well, I think just a .res4 would be enough. Could you upload it as an attachment to this bug?
Andreas Wollbrink - 2012-09-19 17:00:52 +0200
Created attachment 309 res4 file noise balncing set to GradOrd1
Jan-Mathijs Schoffelen - 2012-09-19 17:01:19 +0200
Thanks.
Jan-Mathijs Schoffelen - 2012-09-20 12:09:32 +0200
changing line 212 in ctf2grad to also keep the unused coils seems to recover the channel positions. The updated code (fieldtrip/fileio/private/ctf2grad.m) will be available in tonight's ftp-release, but is already available at google code: http://code.google.com/p/fieldtrip/source/checkout Could you check whether it works now? This would mean that the header information needs to be read (and the hdr.grad needs to be put into the data structure) before you can proceed with the creation of the source model. I hope that this fix fixes the downstream issue, with ft_prepare_sourcemodel not adequately detecting the inside of the brain...
Andreas Wollbrink - 2012-09-20 14:32:21 +0200
(In reply to comment #19) SUCCESS: after using the new fieldtrip version the grad.chanori and grad.chanpos kept their original values after applying ft_denoise_synthetic in order to change the data noise balance level from 1 (acquisition) to 3. furtheron I successfully could use the re-balanced data to prepare a leadfield matrix having entries for 300 channels (MEG + MEGREF) for each source I did not understand your comment: 'This would mean that the header information needs to be read (and the hdr.grad needs to be put into the data structure) before you can proceed with the creation of the source model. I hope that this fix fixes the downstream issue, with ft_prepare_sourcemodel not adequately detecting the inside of the brain' Do I have to use ft_read_header prior to preparing a source model? It seems to work without this additional step.
Jan-Mathijs Schoffelen - 2012-09-20 14:40:25 +0200
Hi Andreas, No you don't need to use ft_read_header, but my comment related to the fact that you may have wanted to use data that was already preprocessed and existed as .mat file on your filesystem. In these data structures, the gradiometer definition pre-dates the fix. Thanks for the feedback.
Robert Oostenveld - 2014-04-16 17:45:25 +0200
Hi JM, In https://code.google.com/p/fieldtrip/source/diff?spec=svn9260&r=9260&format=side&path=/trunk/test/test_bug1708.m you added some code and a test file to the test script for this specific bug. That test file cannot be found on the usual location. Could you copy it there and rename it to bug1708.mat for consistency. thanks, R
Jan-Mathijs Schoffelen - 2014-04-17 09:52:21 +0200
hmmm, I cannot find the file anymore :(. I suspect that I created a dummy data structure based on the .res4 sent to us by Andreas. This contained a first order synthetic gradient balancing. Let me try to reconstruct a data structure like this.
Eelke Spaak - 2015-02-11 14:16:56 +0100
(In reply to Jan-Mathijs Schoffelen from comment #23) The test data for the bug is still missing.
Jan-Mathijs Schoffelen - 2015-02-11 15:16:03 +0100
Yes indeed.
Jan-Mathijs Schoffelen - 2015-02-11 15:20:12 +0100
Sorry guys, I really don't know where to find this data anymore. I suggest to uncomment in the test function the part that uses this data.
Jan-Mathijs Schoffelen - 2015-02-11 15:34:14 +0100
unfixable due to lost data.