[FieldTrip] Fwd: source localization difficulties

Kanal Eliezer ekanal at cmu.edu
Tue Sep 27 21:23:57 CEST 2011


Unfortunately, it looks like redoing the alignment didn't help. I re-ran `ft_volumerealign` in interactive, and it did add the correct field to the output structure, but the brain is still facing the wrong way.

Is it possible that FieldTrip is ignoring this field when plotting? The plotting functions are pretty complex, and are even more obfuscated than usual due to all the transforms used in aligning everything, so I don't want to try to troubleshoot this one myself since I'd almost certainly find the wrong thing.

In the end, I fixed the problem by simply taking vol.bnd.pnt and vol.bnd.tri, applying cart2sph, adding pi/2, and applying sph2cart. However, this is a workaround rather than a direct fix. Still, if anyone else has this problem, I'm attaching the code below... it seems to have worked.

Elli

~~~

tmp = vol;

% transform to spherical coords
[tmp.bnd.pnt(:,1) tmp.bnd.pnt(:,2) tmp.bnd.pnt(:,3)] ...
= cart2sph( ...
    tmp.bnd.pnt(:,1), ...
    tmp.bnd.pnt(:,2), ...
    tmp.bnd.pnt(:,3) );
[tmp.bnd.tri(:,1) tmp.bnd.tri(:,2) tmp.bnd.tri(:,3)] ...
= cart2sph( ...
    tmp.bnd.tri(:,1), ...
    tmp.bnd.tri(:,2), ...
    tmp.bnd.tri(:,3) );

% rotate as necessary
tmp.bnd.pnt(:,1) = tmp.bnd.pnt(:,1) + pi()/2;
tmp.bnd.tri(:,1) = tmp.bnd.tri(:,1) + pi()/2;

% transform back to cartesian
[tmp.bnd.pnt(:,1) tmp.bnd.pnt(:,2) tmp.bnd.pnt(:,3)] ...
= sph2cart( ...
    tmp.bnd.pnt(:,1), ...
    tmp.bnd.pnt(:,2), ...
    tmp.bnd.pnt(:,3) );
[tmp.bnd.tri(:,1) tmp.bnd.tri(:,2) tmp.bnd.tri(:,3)] ...
= cart2sph( ...
    tmp.bnd.tri(:,1), ...
    tmp.bnd.tri(:,2), ...
    tmp.bnd.tri(:,3) );

vol = tmp;



On Sep 27, 2011, at 2:14 PM, Belluscio, Beth (NIH/NINDS) [E] wrote:

> OK, Elli, I think you have the source of your problem - I'm glad that helped.  To redefine the alignment, you can use ft_volumerealign in interactive mode.  Be sure to read the instructions that come up in your matlab workspace simultaneously with the image so that you mark your volume as you wish (I found this a little confusing initially). As you mark your landmarks (eg l, r, n or a,p,s) you should also see the coordinates written out in the workspace.  This should confirm that your realignment is taking place.  After you have done this, you can check it again with the ft_determine_coordsys to make sure.  
> Beth.
> 
> -----Original Message-----
> From: Kanal Eliezer [mailto:ekanal at cmu.edu] 
> Sent: Tuesday, September 27, 2011 1:41 PM
> To: Email discussion list for the FieldTrip project
> Subject: Re: [FieldTrip] Fwd: source localization difficulties
> 
> Hello Beth -
> 
> I actually hadn't tried using `ft_determine_coordsys` on the `ft_prepare_headmodel` output, and it turns out that it's incorrect; it has the anterior along the Y axis, when it should be along the Y. However, changing it doesn't seem to do anything! I.e., using `ft_determine_coordsys` to redefine the alignment, and then re-running `ft_plot_vol` - or even re-running `ft_determine_coordsys` on the new structure - doesn't seem to change anything! The field `coordsys` has been added (and now reads "ras"), but this doesn't seem to affect anything. Is this a bug? Do I need to apply a transformation function to make the new coordsys take effect? Thanks -
> 
> Elli
> 
> 
> On Sep 27, 2011, at 9:35 AM, Belluscio, Beth (NIH/NINDS) [E] wrote:
> 
>> Elli-
>> I had similar problems at one point.  You may already have tried this, but for what it's worth, here are a couple of suggestions:  you can check each type of volume or array with ft_determine_coordsys.  This will give you an image with the x,y,z coordinates superimposed so that you can check directly what type of coordinate system is attached to the volume.  Secondly, when using ft_volumerealign, interactive, make sure you are not incorrectly identifying right and left.  Sometimes in the conversion of DICOM to another system, left and right are switched.   
>> Hope this helps.
>> Beth.
>> 
>> 
>> Beth Belluscio MD-PhD
>> Clinical Fellow
>> Human Motor Control Section
>> NINDS, NIH
>> 301-402-3495
>> 
>> 
>> 
>> -----Original Message-----
>> From: Kanal Eliezer [mailto:ekanal at cmu.edu] 
>> Sent: Tuesday, September 27, 2011 8:50 AM
>> To: Email discussion list for the FieldTrip project
>> Subject: Re: [FieldTrip] Fwd: source localization difficulties
>> 
>> Thanks for forwarding the message to the list.
>> 
>> Just to clarify, the reconstruction worked fine; the brain looks good. The problem is that it's facing the wrong way; in the, the helmet is facing left/back, and the brain is turned 90 degrees to the right (facing forward in the image). If anyone knows how to either correct it as it is or how to re-run the analysis to prevent it from happening I'd be most appreciative. If any more details are needed, please just ask! Thanks -
>> 
>> Elli
>> 
>> 
>> --------------------
>> Eliezer Kanal, Ph.D.
>> Postdoctoral Fellow
>> Center for the Neural Basis of Cognition
>> Carnegie Mellon University
>> 4400 Fifth Ave, Suite 110A
>> Pittsburgh PA 15213
>> P: 412-268-4115
>> F: 412-268-5060
>> 
>> 
>> On Sep 27, 2011, at 2:51 AM, jan-mathijs schoffelen wrote:
>> 
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Kanal Eliezer <ekanal at cmu.edu>
>>>> Date: September 26, 2011 9:45:00 PM GMT+02:00
>>>> To: jan-mathijs schoffelen <jan.schoffelen at DONDERS.RU.NL>
>>>> Subject: Re: [FieldTrip] source localization difficulties
>>>> 
>>>> Hello Dr Schoffelen -
>>>> 
>>>> Thanks for the advice. The way I got this part to work was to use SPM to convert my DICOM files to NIfTI ('*.img') and use `ft_read_mri` on that file, instead of reading the DICOM files directly. Using this method, I was able to reconstruct well.
>>>> 
>>>> However, it seems that there's another related issue. When running the
>>>> 	ft_plot_sens(data_preprocessed.hdr.grad);
>>>> 	hold on;
>>>> 	ft_plot_vol(vol);
>>>> check, I got the attached image. Do you have any idea why it's doing that? Please let me know if I can provide any more details which could help troubleshoot. 
>>>> 
>>>> In case it's relevant, I did notice that the output structure of the `ft_volumerealign` function (run with method='interactive') contained the following field:
>>>> 	mri_realign.coordsys = 'ctf';
>>>> That can't be correct. I'm pretty sure it should be 'nifti'. However, I tried re-running `ft_volumesegment` after manually changing that value, and the figure looks the same.
>>>> 
>>>> Any help would be most appreciated! Thanks -
>>>> 
>>>> Elli
>>>> 
>>>> 
>>>> 
>>>> <check.jpg>
>>>> On Sep 24, 2011, at 3:09 AM, jan-mathijs schoffelen wrote:
>>>> 
>>>>> Hi Elli,
>>>>> 
>>>>>> Hello Dr. Schoffelen -
>>>>>> 
>>>>>> I sent a response to the below email, but I think it got lost in the shuffle. I tried what you suggested, and I got the image attached below (matlab figure).
>>>>>> 
>>>>>> Two questions: (1) What could be the cause of this poor alignment? This isn't right/left flipping, as the nose also looks to be in the back. (2) Do you have any idea why the reconstruction of the MRI looks so poor? FreeSurfer reconstructions looked much "healthier".
>>>>> 
>>>>> To combine both questions into 1 answer, I wouldn't say that the alignment is bad, it's the segmentation that seems to be completely off. This usually happens, when FieldTrip assigns the wrong coordinate system to the MRI. For the segmentation to work, SPM needs an approximate coregistration of the MRI in MNI-space. FieldTrip tries to achieve this, and needs the tag mri.coordsys for this. This tag is usually set after a pass through ft_volumerealign, where you can specify a cfg.coordsys (I just noticed this as an undocumented option: perhaps that needs to change). By default, this tag is set to 'ctf', see http://fieldtrip.fcdonders.nl/faq/how_are_the_different_head_and_mri_coordinate_systems_defined for a definition of the coordinate systems. If the coordinate system in which the sensors are defined differs from the ctf coordinate system, causing a bad initial alignmnent prior to the segmentation and a worthless segmentation.
>>>>> 
>>>>>> You mentioned below that I could simply load the up freesurfer files and go from there. All the *.mgz files I've found from freesurfer processing are simply volumetric MRI files. The surface files are stored in a variety of formats with seemingly no file extension. Is there a way to load FreeSurfer surfaces, or should I be using `ft_prepare_headmodel` to do that?
>>>>> 
>>>>> The ft_read_headshape function should be able to read freesurfer triangle and quadrangle files. Use it as ft_read_headshape(filename, 'fileformat', 'freesurfer-triangle_binary');
>>>>> 
>>>>>> Thanks -
>>>>>> 
>>>>>> Eliezer Kanal
>>>>> 
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Jan-Mathijs
>>> 
>>> Jan-Mathijs Schoffelen, MD PhD 
>>> Donders Institute for Brain, Cognition and Behaviour, 
>>> Centre for Cognitive Neuroimaging,
>>> Radboud University Nijmegen, The Netherlands
>>> J.Schoffelen at donders.ru.nl
>>> Telephone: +31-24-3614793
>>> 
>>> _______________________________________________
>>> fieldtrip mailing list
>>> fieldtrip at donders.ru.nl
>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> 
>> 
>> _______________________________________________
>> fieldtrip mailing list
>> fieldtrip at donders.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> 
>> _______________________________________________
>> fieldtrip mailing list
>> fieldtrip at donders.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> 
> 
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> 
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip





More information about the fieldtrip mailing list