Dear Panagiotis and Anette,
Thanks a lot for your input and for the testing script which was very
helpful. I think I fixed the bug some time ago but it was after the
last public update. Could you please put the attached file in your
@meeg folder and see if it fixes the problem?
Thanks,
Vladimir
On Fri, Nov 11, 2011 at 8:26 PM, Panagiotis Tsiatsis
<[log in to unmask]> wrote:
> Dear Vladimir and Anette,
>
> I think i ve found the problem, and also provided an ugly and possibly
> over-complicated fix for Anette's problem. i might be totally wrong of
> course. But this issue relates to a similar problem that I had with this
> function as well concerning the coor2d assignment.
>
> The problem seems to be the functionality of coo2d. At that time I had
> mentioned a similar problem which made me make the following modification:
>
> %I commented this line
> % Dnew = coor2D(Dnew, [], coor2D(D, chanind));
>
> %And substituted it with these two
> MEG_Channels = (D.meegchannels('MEG'));
> Dnew = coor2D(Dnew, [], coor2D(D, MEG_Channels));
>
> Now that Annete needs to remove channels (and possibly MEG channels) the
> above modification is wrong.
>
> So this is where I think that maybe the problem lies: if you run the
> following code (just load on variable 'A' an meg spm object), you might be a
> bit surprised at the result. At least, I was.
>
> % =======================================================================
> % == CODE STARTS HERE
> % =======================================================================
> load an spm MEG object A
> A
> display('Total Number of Channels in A')
> A.nchannels
>
> display('Create a new object C as equal to A')
> C = A;
>
>
> display('Set Coord_A to be A.coor2D and Coord_C to be C.coor2D');
>
> Coord_A = A.coor2D;
> Coord_C = C.coor2D;
>
>
> display('Find where the matrices mismatch..')
>
> Total_Mismatches = sum(find(Coord_A(1,:) ~= Coord_C(1,:))) +
> sum(find(Coord_A(2,:) ~= Coord_C(2,:)))
>
> display('No Mismatches, as expected...')
>
> display('Now assign the coords of A to C via coor2d, exactly as spm_eeg_crop
> does...')
> C = coor2d(C,[],coor2d(A,[1:A.nchannels]));
>
> display('Update Coord_A to be A.coor2D and Coord_C to be C.coor2D');
> Coord_A = A.coor2D;
> Coord_C = C.coor2D;
>
>
> display('Find where the matrices mismatch..')
> Total_Mismatches = sum(find(Coord_A(1,:) ~= Coord_C(1,:))) +
> sum(find(Coord_A(2,:) ~= Coord_C(2,:)))
>
> display('Surprise..')
>
> % =======================================================================
> % == CODE ENDS HERE
> % =======================================================================
>
> AS you will see, the result is fine as expected when the coordinates are
> copied via an assignment operation on the objects' level, but they are
> completely wrong in the case of an assignment via the coor2d function.
>
> I am attaching you a solution which might be wrong and overcomplicated but
> it seemed to work fine for me. I also tried to remove channels of different
> kinds and also MEG channels from different positions to make sure that the
> solution is robust (ie. it could make a difference if the first MEG channels
> in line are removed instead of channels that come later on). I ve put some
> comments but I am a bit tired at the moment so please doublecheck it.
>
> Also, keep in mind that this is only an MEG CTF specific solution. I would
> say more of a hint that a solution, I hope I don't end up misleading you.
>
>
> Best,
> Panagiotis
>
>
>
>
> On 11/11/2011 4:16 PM, Anette Giani wrote:
>>
>> Dear Vladimir,
>>
>> Thanks for your response. You are right, 2D locations are preserved. At
>> least if I type: coor2D(D), I get the same locations before and after
>> cropping. Interestingly, if I want to look at the topology using the GUI,
>> the message still appears. I tried to look in the code and I think it has
>> something to do with in spm_eeg_review_callbacks (line 209: pos(:,1) =
>> [D.channels(I).X_plot2D]';). Even though I do not really understand what
>> happens there, I think it is strange that in the uncropped case the
>> variable
>> pos is about the size of the number of channels, while in the cropped case
>> it is 277 times as large.
>>
>> This happens for any dataset that I tried. If you still cannot replicate
>> the
>> error please let me know. In that case I will try to send you one example
>> dataset.
>>
>> Best,
>> Anette
>>
>>
>>
>> -----Original Message-----
>> From: SPM (Statistical Parametric Mapping) [mailto:[log in to unmask]] On
>> Behalf Of Vladimir Litvak
>> Sent: Friday, November 11, 2011 12:35 PM
>> To: [log in to unmask]
>> Subject: Re: [SPM] MEEG: grand mean and crop
>>
>> Dear Anette,
>>
>> The crop tool should preserve the 2D locations. It is in the code and I've
>> just checked on my example and there was no problem. Perhaps send me your
>> dataset before cropping and which channel you removed and I'll look at it.
>> You can also try to use 'Prepare' to re-create the 2D locations and see if
>> it helps (don't forget 'apply' and 'save').
>>
>> Best,
>>
>> Vladimir
>>
>> On Fri, Nov 11, 2011 at 9:13 AM, Anette Giani
>> <[log in to unmask]> wrote:
>>>
>>> Dear all,
>>>
>>> For the analysis of my MEG data, I would like to calculate the grand
>>> mean over all subjects. However, for technical reasons, data of one
>>> subject contains 1 channel less than the data of the others. Is there
>>> a way to choose the channels for which the grand mean should be
>>> calculated? I tried to crop the data of the remaining subjects.
>>> However, after cropping it seems like 2d channel positions are lost.
>>> Hence, if I want to look at the topology of the cropped data a message
>>> appears: "Get 2d positions for these channels!".
>>>
>>> Looking forward to your suggestions!
>>> Anette
>>>
>
>
> --
> Panagiotis S. Tsiatsis
> Max Planck Institute for Biogical Cybernetics
> Cognitive NeuroImaging Group
> Tuebingen, Germany
>
>
|