Dear Panagiotis,

Re the first problem there was indeed a bug in my fix (see attached).
Re the second problem it will stay unfixed as long as I can't
reproduce it so you can't ignore my request to provide an example and
expect that I will somehow fix it anyway.

In general, the functionality you need can be achieved with
spm_eeg_convert where you can re-convert your spm8 dataset (select the
mat file) and ask for a segment of continuous data. That will also
work for very large datasets unlike spm_eeg_crop which was
specifically designed for epoched and TF data.

Vladimir

On Wed, Apr 6, 2011 at 8:43 PM, Panagiotis Tsiatsis
<[log in to unmask]> wrote:
>  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
>
>