Dear Panagiotis,

On Fri, Jul 2, 2010 at 3:52 PM, Panagiotis Tsiatsis
<[log in to unmask]> wrote:
> Dear all,
>
> In my MEG recordings (CTF machine) I face a lot of movement (~5mm for most
> subjects thoughout most of the recordings and I would like to somehow
> correct for it.

First of all 5 mm is not that much (or maybe I'm biased by my own work
with patients). Yes there are good subjects who can keep very still
but I'd say 5 mm is quite typical. It also depends on the length of
your trials/blocks. Since any kind of correction of head location is
likely to introduce some noise or discard some data, perhaps you just
don't need it. It won't help you now but for the future perhaps you
should just try positioning your subjects more precisely and
restricting their head movements better with something like an
inflatable head band. There are different tricks used by different
labs. Perhaps other people will comment.

>In a previous mail that I had sent to the list, I was
> advised by Vladimir to use the function meg_head_loc:
>
>
> "There is a function in MEEGtools called  'Use CTF head localization'
> (spm_eeg_megheadloc). You can use it to do things like rejecting
> trials with excessive head movements or *outlying head locations or to
> recompute the sensor locations to better fit the part of the data that
> you are actually analysing.*"
>
>
> In the script header it is mentioned that
>
>
> "Use head localization of CTF to select/reject trials based on head
> position and *(optionally) correct the sensor coordinates to correspond to
> the selected trials.*"
>
>
> I tried to go through the code but I could not get much of it. I can see
> that it uses that continuous localization info but I don t exactly know how.
> Could somebody give me a hint? Does this function somehow re-reference the
> coil positions to a standard space? From the comments in the file, this does
> not seem to be the case:
>
>
>    % Here the idea is to put a 'sphere' or 'hypercylinder' in the space of
> trial location whose
>    % radius is 'threshold' and which captures as many trials as possible.
> For this we first look for the point around which the
>    % density of trials is maximal. We put the cylinder there and then try to
>    % optimize its position further to include more trials if possible.
>
>    % The density is compute in PCA space of at most 3 dimensions
>
>


The function can do several things. The part that you are referring to
can do selection across trials. It looks at the average head position
in each trial as a point and then given some maximal distance you
specify, let's say 3 mm tries to find the maximal group of trials
which will be within 3 mm of each other. It then marks the other
trials as bad and recomputes the sensor locations to correspond to the
mean of the selected group of trials.


> Some further questions:
>
> If the algorithm tries to take into account all the trials in a file (still
> not clear to me exactly how, even after reading the above description) then
> I guess it makes more sense to apply the script on a concatenated file of
> all sessions, rather than applying it first for each session individually
> and then merge the sessions to a concatenated file, right?
>

Yes you can do that, although if you demand a very strict position
similarity and don't take any measures to reposition your subject
precisely between sessions it's unlikely that you'll have very close
head locations between session.

> I compared the D.sensors('meg').pnt and D.sensors('meg').ori fields in both
> cases and they are different. (I guess these fields represent only the
> initial coil positions, right?
>

It's not clear what you mean by 'both cases' but those fields
represent the locations read from the dataset header and these
locations usually correspond to those measured at the beginning of a
run. If you merge across sessions SPM just takes the locations from
the first file, which is rather crude. So perhaps an improvement would
be just to use megheadloc to recompute the locations to correspond to
the average of all trials without rejecting anything. I just couldn't
do that by default because this function is CTF-specific.

> Another thing that I am not sure of, is if and how the inversion algorithms
> take advantage of the continuous CTF localization info. Do they only take
> into account the initial coil positions?

Yes

> Wouldn't it make more sense to
> calculate a mean value for all the coil position within each trial? Is a
> mean position value used when only the mean of a condition is used for
> inversion?

The inversion doesn't recompute sensor positions at all. If you don't
use spm_eeg_megheadloc then the inversion just used those initial
sensor positions that are stored in the file. If you do use them the
inversion will use the positions recomputed by the function. Again the
answer to 'would it make sense' depends on your data. If for instance
between the time you start the recording and the time you deliver your
first stimulus the subject moves his head by 10 cm it would definitely
make a lot of sense to recompute his position using data from
continuous head tracking.

>
>
> And finally a silly and naive question, please correct me if I am wrong, I
> guess the sensor position correction is only useful for source localization,
> i.e. even after applying it it is still not sensible to draw comparisons
> between subjects in the sensor space as it is only the positions of the
> channels and not the waveforms them selves that are affected. In any case,
> could the meeg_headloc algorithm be used to normalize the coil positions
> across subjects? Is there a way to bring all of them to a normal "coil
> position" space so that analysis in the sensor space would make sense?
>

No, it's not very useful for sensor space analysis except you can
reject the trials with outlier head locations and thus make your
sensor maps more focal. In the next SPM release there will be a new
method developed by Karl for realignment of leadfields across subjects
for source reconstruction. I'm planning to take the code out and make
it into a stand-alone tool for normalizing sensor data. But I don't
know when I'll get to doing that as I have higher priority stuff.

> Any extra information on the meg_head_loc script is highly appreciated!
>

One thing I can say (I think I wrote it before) that I ran the same
analysis with different ways of taking head movements into account and
got the same results. But again, that might be because of the nature
of that analysis. One thing you can try is running the function with a
very liberal rejection threshold and just letting it recompute the
sensor locations. It will show you the difference so you can see how
much it matters. Let me know if you need help getting it to run.


Best,

Vladimir