Back to the main page.

Bug 572 - ft_megplanar outputs old ICA channel labels (and too many channels)

Reported 2011-04-08 14:27:00 +0200
Modified 2011-05-05 21:24:34 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P1 normal
Assigned to: Stephen Whitmarsh
Depends on:
See also:

Stephen Whitmarsh - 2011-04-08 14:27:53 +0200

ft_megplanar outputs 3x as many channels+labels as it got in, instead of 2x (e.g. runica001_dH, runica200_dV + original channels/labels). Using ICA channels/labels of a several previous processing steps makes no sense to me...

Stephen Whitmarsh - 2011-04-08 14:28:19 +0200

btw, this was on timelockeddata

Stephen Whitmarsh - 2011-04-08 14:31:10 +0200

Created attachment 40 an averaged timelock datafile on which the problem occured

Jan-Mathijs Schoffelen - 2011-04-08 15:16:00 +0200

the problem is caused by the function channelposition. Here the gradiometer structure is reverted to its 'unbalanced' state, i.e. it undoes the previous balancing step. In your case the last balancing step was a linear projection applied in ft_rejectcomponent, which transformed from ica-space back to sensor space. channelposition must be made robust against this, moreover we need to implement consistent handling of balancing throughout the code

Stephen Whitmarsh - 2011-04-08 15:27:24 +0200

Thanks Mattie! Shall I remove the cfg as a workaround? In any case I think I will balance my poor self now by orienting tangentially to the earth's gravitational field. On the grass that is. :-)

Jan-Mathijs Schoffelen - 2011-04-08 16:23:37 +0200

I think that if you temporarily remove the grad from the data, and replace this with an original grad, it should work. Note that we have to look into how the grad.tra looks for the ft_rejectcomponent data if you want to do a source reconstruction on this type of data

Stephen Whitmarsh - 2011-04-08 16:31:37 +0200

I already replaced the .grad from a previous step and it somehow got it out of the cfg. I agree that we should make 100% clear what happens with the grad field in rejectcomponents as well as any other functions that handle it, e.g. denoising with 3rd order gradient, which is still a bit unclear for me.

Jan-Mathijs Schoffelen - 2011-04-22 21:11:38 +0200

Please test it. I updated the code with respect to balancing and keeping track of subsequent steps. It should work now. Verify this and close it if it works.

Stephen Whitmarsh - 2011-04-26 15:13:11 +0200

It seems to work for me! Closing bug

Robert Oostenveld - 2011-05-05 21:24:34 +0200

bulk action: closed all bugs with status "resolved/fixed"