Hello Vladimir and dear all,

Apologies in advance for the long e-mail, I am trying to be as clear as 
possible. I updated my spm version today but I am facing some problems 
with spm_eeg_crop when I try to apply it to my data (CTF MEG)


Problem A.] As we had discussed in the past, when trying to crop a 
continuous file:

On 2/16/2011 4:57 PM, Vladimir Litvak wrote:
>
>> 2.The cropped file (where only a few non-trial seconds from the start and
>> from the and are missing) contains exactly the same number of events as the
>> original continuous file. Why??? It seems that some zombie events are
>> retained after cropping!
>>
>>
> That's indeed a bug, due to the fact that I wasn't planning this
> function to be used on continuous data. I now fixed it and it'll be in
> the next update.
>

I saw your fix in the code to retain only the correct events in the 
cropped file, but the problem is that when I am trying to use the 
function on a continuous CTF MEG data file, I am getting the following 
error:

SPM8: spm_eeg_crop (v4202)                         20:05:54 - 06/04/2011
 =======================================================================
??? Error using ==> subsindex
Function 'subsindex' is not defined for values of class 'struct'.

Error in ==> getfield at 46
         f = f(index{:});

Error in ==> getset at 25
         res{i} = getfield(this, parent, {ind(i)}, fieldname);

Error in ==> meeg.events at 11
res = getset(this, 'trials', 'events', varargin{:});

Error in ==> spm_eeg_crop at 103
    Dnew   = events(Dnew, ev);


I could use the function properly before the update. The parameters that 
I pass to the function are the following


                 S = [];
                 S.D = D; %where this is the origin continuous CTF MEG 
data file
                 S.timewin = [(Time_of_First_Trial_Onset_in_ms - 
Time_Offset_in_ms) (Time_of_Last_Trial_Onset_in_ms + Time_Offset_in_ms)]
                 S.freqwin = [];
                 S.channels = 'all'

                 D = spm_eeg_crop(S);
                 D.save;

Any ideas?


Problem B.] When using crop in epoched data it seems to work fine. But 
still, as I wrote before, in the case that the trials have been cropped 
I get the following warning later on through the analysis when I am 
converting the trials to images

Warning: Duplicate x-y data points detected: using average of the z values.
 > In griddata at 107
   In spm_eeg_convert2scalp at 205


This only occurs if I crop the data (if you look back in my previous 
e-mail, you will see that this was also happening when I was cropping 
the continuous file.

 From our previous communication (e-mail title "Warning in 
spm_eeg_convert2scalp (griddata) & spm_eeg_crop"]

==============


The problem seems to appear in spm_eeg_crop when applied on a continuous
>  file  to and more specifically somewhere in the creation of the new object:
>
>  Dnew = coor2D(Dnew, [], coor2D(D, chanind));
>
>  as some channels do indeed have the same coordinates :
>

>> >>>  size(coor2D(D, chanind)')
>
>  ans =
>
>     337     2
>

>> >>>  size(unique(coor2D(D, chanind)','rows'))
>
>  ans =
>
>     335     2
>
>
>  The above number shows that spm_eeg_crop indeed puts in the coor2D matrix
>  (or tries to put) the coordinates of all available channels. Up to now (and
>  correct me if I am wrong) I knew that the coor2D matrix contains the
>  coordinates of the MEGGRAD channels only. So I modified the code as follows
>  :
>
>  MEG_Channels = (D.meegchannels('MEG'));
>  Dnew = coor2D(Dnew, [], coor2D(D, MEG_Channels));
>
>
>  *And indeed the conversion to images of subsequent files was executed
>  without warnings*. So, is this a bug or am I going the wrong direction here?
>

(Vladimir wrote:)
I tried this on my CTF dataset and I don't get identical 2D
coordinates. So this is something that happens for your data and I'm
not sure why. If you send me an example I can look. In general this
code should work as it is because 2D coordinates are defined for all
channels (for non-scalp channels these are just points on a square
grid).


==============



So these two problems still remain unresolved for me... Any help would be highly appreciated.

Thanks and best

Panagiotis






>> 3.  Please note that there appears to be one more problem with spm_eeg_crop
>> and continuous data :
>>
>> The line Dnew = badchannels(Dnew, [], badchannels(D, chanind)); always
>> results in an error when there are no bad channels, i.e. when
>> isempty(D.badchannels) == 1. so i have substituted the above line with
>>
>> if isempty(D.badchannels) == 0
>>      Dnew = badchannels(Dnew, [], badchannels(D, chanind));
>> end
>>
> I can't reproduce this problem either. The code should work also for
> no bad channels because badchannels(D, chanind) always returns a
> vector of 0/1
>
> Best,
>
> Vladimir
>
>
>> I suspect I should put an 'else' condition somewhere there, but of course
>> you are the expert on this  :)
>>
>> Thanks again and all the best,
>> Panagiotis
>>
>> On 2/7/2011 8:10 PM, Vladimir Litvak wrote:
>>> Dear Panagiotis,
>>>
>>> Try doing:
>>>
>>> spm_eeg_load
>>> D.coor2D(D.meegchannels('MEG'))
>>>
>>> and look which of the channels have the same 2D coordinates. In
>>> principle this should not happen for CTF MEG. You can also look in
>>> 'Prepare' tool at the 2D channel layout an modify it if necessary or
>>> load a template layout from EEGtemplates.
>>>
>>> Best,
>>>
>>> Vladimir
>>>
>>> On Sun, Feb 6, 2011 at 5:23 PM, Panagiotis Tsiatsis
>>> <[log in to unmask]>    wrote:
>>>>   Dear All,
>>>>
>>>> When I am converting my CTF MEG epoched data to images, I am getting the
>>>> following warning:
>>>>
>>>> Warning: Duplicate x-y data points detected: using average of the z
>>>> values.
>>>>> In griddata at 107
>>>>   In spm_eeg_convert2scalp at 204
>>>>
>>>> My settings are:
>>>>
>>>>             S = [];
>>>>             S.n = 32;
>>>>             S.Fname = Concatenated_File_Name_Time;
>>>>             S.interpolate_bad = 1;
>>>>             S.modality = 'MEG';
>>>>
>>>> I also have EOG channels whose chantype has been set to 'EEG' during the
>>>> conversion (this of course should not interfere since I ve selected my
>>>> modality to be 'MEG').
>>>>
>>>> By browsing the Mathwoks forum, I suspect that this happens when nearby
>>>> values get very similar (as is the case with MEG data).
>>>>
>>>> Anybody seen that before? Any intuitions?
>>>>
>>>> Thanks and best,
>>>> Panagiotis
>>>>
>>>>
>>>> --
>>>> Panagiotis S. Tsiatsis
>>>> Max Planck Institute for Biological Cybernetics
>>>> Cognitive NeuroImaging Group
>>>> Tuebingen, Germany
>>>>
>>
>> --
>> Panagiotis S. Tsiatsis
>> Max Planck Institute for Biological Cybernetics
>> Cognitive NeuroImaging Group
>> Tuebingen, Germany
>>
>>


-- 
Panagiotis S. Tsiatsis
Max Planck Institute for Biological Cybernetics
Cognitive NeuroImaging Group
Tuebingen, Germany