Back to the main page.

Bug 2146 - ica cleanup problems with numcomponent < numchannel

Status ASSIGNED
Reported 2013-04-27 12:26:00 +0200
Modified 2013-05-09 08:03:22 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Johanna
URL:
Tags:
Depends on:
Blocks:
See also:

Robert Oostenveld - 2013-04-27 12:26:30 +0200

on behalf of Ana: I've always run an ICA to remove eye blinks and heartbeat, but instead of saving the data file, I would save the unmixing matrix and then do the component rejection later, as a part of some other script. So far, I've always done this using the same number of components as there are MEG channels. This time I opted for using a smaller number of components, but I realized that it does not work unless I transpose the unmixing (i.e. comp.topo) matrix. To clarify, this is what I do: cfg = []; cfg.unmixing = comp.topo'; cfg.topolabel = comp.topolabel; comp_data = ft_componentanalysis(cfg, data); If I don't transpose comp.topo, then I get an error saying that the number of channels is not accurate. Is this the way it's supposed to be? It is not clear from the text of 'help ft_componentanalysis', although there it is mentioned that the unmixing matrix is of dimensions NxN (and not NxM, which is my case). I'm now starting to wonder whether I should have always transposed this matrix.


Johanna - 2013-04-29 11:27:51 +0200

Near the end of ft_componentanalysis, there is: % store mixing/unmixing matrices in structure comp.topo = mixing; comp.unmixing = unmixing; Thus, I think you may be using the wrong matrix and instead should use: cfg.unmixing = comp.unmixing; Perhaps your 'comp' is from an older version which had .topo as output and no .unixing and .mixing? Either way, I agree that the documentation should allow for 'unmixing' to be MxN (comps X channels).