Back to the main page.
Bug 572 - ft_megplanar outputs old ICA channel labels (and too many channels)
| Status | CLOSED FIXED |
| 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 |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| 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